Document
Important notice! KWF Email scanner found a virus in following attachment: Notice.zip Content type: application/octet-stream Additional information from antivirus: W95/Spaces.gen Attachement has been removed by firewall.
Response from Rolia.net
This email account no longer exists. To contact the management team of Rolia.net, please visit: http://www.rolia.net/mem/mem_mailRolia.php Thank you! ´Ëµç×ÓÓÊÏäÒѾֹͣʹÓÃ. Èç¹ûÄúÒªÁªÏµÏàÔ¼¼ÓÄôóÍøÉÏÉçÇø(Rolia.net), Çë·ÃÎÊ´ËÍøÒ³: http://www.rolia.net/mem/mem_mailRolia.php лл! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [GUMP@brutus]: jakarta-tomcat-5/jakarta-tomcat-5 success
Please take me off this mail list. Many Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 25 July 2004 10:46 To: [EMAIL PROTECTED] Subject: [EMAIL PROTECTED]: jakarta-tomcat-5/jakarta-tomcat-5 success To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project jakarta-tomcat-5 *no longer* has an issue. Project State : 'Success' Full details are available at: http://brutus.apache.org/gump/public/jakarta-tomcat-5/jakarta-tomcat-5/i ndex.html That said, some snippets follow: The following annotations were provided: -DEBUG- Jar [naming-resources.jar] identifier set to jar basename: [naming-resources] -DEBUG- Jar [servlets-default.jar] identifier set to jar basename: [servlets-default] -DEBUG- Jar [naming-common.jar] identifier set to jar basename: [naming-common] -DEBUG- Jar [catalina.jar] identifier set to jar basename: [catalina] -DEBUG- Jar [bootstrap.jar] identifier set to jar basename: [bootstrap] -DEBUG- Jar [servlets-common.jar] identifier set to jar basename: [servlets-common] -DEBUG- Jar [servlets-invoker.jar] identifier set to jar basename: [servlets-invoker] -DEBUG- Dependency on javamail exists, no need to add for property mail.jar. -DEBUG- Dependency on jaf exists, no need to add for property activation.jar. -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property servlet-api.jar. -DEBUG- Dependency on jakarta-servletapi-5-jsp exists, no need to add for property jsp-api.jar. -DEBUG- Dependency on xml-xerces exists, no need to add for property xercesImpl.jar. -DEBUG- Dependency on xml-xerces exists, no need to add for property xml-apis.jar. -DEBUG- Dependency on jakarta-tomcat-util exists, no need to add for property tomcat-util.jar. -DEBUG- Dependency on commons-el exists, no need to add for property commons-el.jar. -DEBUG- Dependency on commons-logging exists, no need to add for property commons-logging-api.jar. -DEBUG- Dependency on commons-modeler exists, no need to add for property commons-modeler.jar. -DEBUG- Dependency on ant exists, no need to add for property ant.home. -DEBUG- Dependency on jsse exists, no need to add for property jsse.home. -DEBUG- Dependency on jmx exists, no need to add for property jmx.home. -DEBUG- Dependency on jmx exists, no need to add for property jmx.jar. -DEBUG- Dependency on jmx exists, no need to add for property jmx-tools.jar. -DEBUG- Dependency on jndi exists, no need to add for property jndi.home. -DEBUG- Dependency on jakarta-regexp exists, no need to add for property regexp.home. -DEBUG- Dependency on jakarta-regexp exists, no need to add for property regexp.jar. -DEBUG- Dependency on javamail exists, no need to add for property mail.home. -DEBUG- Dependency on jakarta-tomcat-coyote exists, no need to add for property tomcat-coyote.home. -DEBUG- Dependency on jakarta-tomcat-jasper_tc5 exists, no need to add for property jasper.home. -DEBUG- Dependency on jaf exists, no need to add for property activation.home. -DEBUG- Dependency on commons-modeler exists, no need to add for property commons-modeler.home. -DEBUG- Dependency on commons-daemon exists, no need to add for property commons-daemon.jsvc.tar.gz. -DEBUG- Dependency on jakarta-struts exists, no need to add for property struts.home. -INFO- Enable verbose output, due to 1 previous error(s). The following work was performed: http://brutus.apache.org/gump/public/jakarta-tomcat-5/jakarta-tomcat-5/g ump_work/build_jakarta-tomcat-5_jakarta-tomcat-5.html Work Name: build_jakarta-tomcat-5_jakarta-tomcat-5 (Type: Build) State: Success Elapsed: 2 mins 41 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/buil d/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build /xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xala n-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/extern al/build/xml-apis.jar org.apache.tools.ant.Main -verbose -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dtomcat33.home=--UnSet-- -Djsp-api.jar=/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr1 52/dist/lib/jsp-api.jar -Djmx.jar=/usr/local/gump/packages/jmx-1_2-ri/lib/jmxri.jar -Djmx.home=/usr/local/gump/packages/jmx-1_2-ri -Djdbc20ext.jar=/usr/local/gump/packages/jdbc2_0/jdbc2_0-stdext.jar -Dregexp.jar=/usr/local/gump/public/workspace/jakarta-regexp/build/jakar ta-regexp-20040725.jar -Dmail.home=/usr/local/gump/packages/javamail-1.3 -Dant.home=/usr/local/gump/public/workspace/ant/dist -Dsite2.home=/usr/local/gump/public/workspace/jakarta-site2 -Dcommons-collections.jar=/usr/local/gump/public/workspace/jakarta-commo ns/collections/build/commons-collections-20040725.jar
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina Context.java
remm2004/07/26 01:09:21
Modified:catalina/src/share/org/apache/catalina/startup
HostConfig.java ContextRuleSet.java
catalina/src/share/org/apache/catalina/core
StandardContext.java
catalina/src/share/org/apache/catalina Context.java
Added: catalina/src/conf context.xml
Log:
- Add code to handle resource relaoding.
- Add one extra element to Context (I couldn't find a way to avoid it).
- Add a global context.xml file, to define two basic reload resources.
- Now, I'll do the new anti locking code.
Revision ChangesPath
1.36 +40 -27
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/HostConfig.java
Index: HostConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/HostConfig.java,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- HostConfig.java 25 Jul 2004 23:35:37 - 1.35
+++ HostConfig.java 26 Jul 2004 08:09:19 - 1.36
@@ -464,28 +464,28 @@
// Assume this is a configuration descriptor and deploy it
log.debug(sm.getString(hostConfig.deployDescriptor, files[i]));
try {
-Context newContext = null;
+Context context = null;
synchronized (digester) {
-newContext = (Context) digester.parse(contextXml);
+context = (Context) digester.parse(contextXml);
}
-if (newContext instanceof Lifecycle) {
+if (context instanceof Lifecycle) {
Class clazz = Class.forName(host.getConfigClass());
LifecycleListener listener =
(LifecycleListener) clazz.newInstance();
-((Lifecycle) newContext).addLifecycleListener(listener);
+((Lifecycle) context).addLifecycleListener(listener);
}
-newContext.setConfigFile(contextXml.getAbsolutePath());
-newContext.setPath(contextPath);
+context.setConfigFile(contextXml.getAbsolutePath());
+context.setPath(contextPath);
// Add the context XML to the list of watched files
deployedApp.reloadResources.put
(contextXml.getAbsolutePath(), new
Long(contextXml.lastModified()));
// Add the associated docBase to the redeployed list if it's a
WAR
boolean isWar = false;
-if (newContext.getDocBase() != null) {
-File docBase = new File(newContext.getDocBase());
+if (context.getDocBase() != null) {
+File docBase = new File(context.getDocBase());
if (!docBase.isAbsolute()) {
docBase = new File(new File(host.getAppBase()),
-newContext.getDocBase());
+context.getDocBase());
}
deployedApp.redeployResources.put(docBase.getAbsolutePath(),
new Long(docBase.lastModified()));
@@ -493,21 +493,18 @@
isWar = true;
}
}
-host.addChild(newContext);
+host.addChild(context);
// Add the eventual unpacked WAR and all the resources which
will be
// watched inside it
-if (isWar unpackWARs (newContext.getDocBase() != null)) {
-File docBase = new File(newContext.getDocBase());
+if (isWar unpackWARs (context.getDocBase() != null)) {
+File docBase = new File(context.getDocBase());
if (!docBase.isAbsolute()) {
docBase = new File(new File(host.getAppBase()),
-newContext.getDocBase());
+context.getDocBase());
}
deployedApp.redeployResources.put(docBase.getAbsolutePath(),
new Long(docBase.lastModified()));
-// FIXME: Add the list of reload resources as given by the
context
-//This list would by default contain
/WEB-INF/web.xml and
-///META-INF/context.xml
-//Add new element in Context
Re: Mod_ajp initial
Graham Leggett wrote: Remy Maucherat wrote: Until I'm shown a mod_proxy (with HTTP) with performance close to mod_jk, my opinion is that we can't use it. As I've pointed out already, mod_proxy is a framework. The performance numbers quoted tested mod_proxy_http, not mod_proxy, which doesn't do anything on it's own. There is no reason why proxy_ajp would be any slower than mod_ajp. The framework itself could be designed in a way which would end up hurting performance. It did happen in Tomcat in the past, and I don't know about mod_proxy since I haven't looked at it, but it could happen. I think you should be more open minded about a possible mod_ajp connector (assuming it ends up being a quality connector), and block it on principle. On the other side of the fence, we have yet to find out that mod_proxy will fully fit our needs. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30291] - Wrong smap in expressions and scriptlets
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30291. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30291 Wrong smap in expressions and scriptlets --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 09:23 --- Created an attachment (id=12217) zip with files - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Remy Maucherat wrote: Graham Leggett wrote: Remy Maucherat wrote: Until I'm shown a mod_proxy (with HTTP) with performance close to mod_jk, my opinion is that we can't use it. As I've pointed out already, mod_proxy is a framework. The performance numbers quoted tested mod_proxy_http, not mod_proxy, which doesn't do anything on it's own. There is no reason why proxy_ajp would be any slower than mod_ajp. The framework itself could be designed in a way which would end up hurting performance. It did happen in Tomcat in the past, and I don't know about mod_proxy since I haven't looked at it, but it could happen. I think you should be more open minded about a possible mod_ajp connector (assuming it ends up being a quality connector), and block it on principle. On the other side of the fence, we have yet to find out that mod_proxy will fully fit our needs. Well I think that we should consider mod_ajp as a jk rewriting for Apache 2.0 (2.1) using all APR/APACHE2.x power. Since we plan to developp an AJP library, it will ease the task for ajp_proxy and we could validate many points like this and have a release rate independant from the HTTPD 2.0/2.1 rr. Of course mod_proxy will be extended by Graham and I'm sure he'll put more and more optimisation in it, giving a better proxy framework to HTTPD 2.x. And when ajp_proxy will be ASF production level ready, it could be included in HTTPD tree. After that we could probably stop mod_ajp or use it as a features labs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Bill Barker wrote: I'm with Graham on this. Personally, I have very little interest in a mod_ajp module, but I am interested in proxy_ajp, proxy_lb, etc. Of course, since j-t-c has long doubled as j-t-sandbox, this means that I'm +0 for committing your stuff there. Well Mladen has been quick to release this initial work and I suspect it will be faster again to make a valid prototype. Now we should know who could works on it ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] proxy lb support - step 1
Hi all,
There has been some serious discussion for building load balancing support
for mod_proxy.
Here is the first in series of patches that will enable this.
The patch adds lb support in scoreboard, so that statuses for each lb worker
can be calculated for each child process.
It uses optional function to retrieve the number of lb workers and
calculates the scoreboard size accordingly.
The other option is to rewrite the scoreboard functionality and use it
inside mod_proxy, but that will cause a strange shm locking observed on some
platforms using jk2 shared memory, cause we cannot create the shm in parent
process.
Right now the lb_score only defines 1024 byte space, that can later be
replaced with real struct members once when the lb functionality gets
frozen.
For now we will simply cast that to the desired structure.
Regards,
MT.
Index: scoreboard.h
===
RCS file: /home/cvspublic/httpd-2.0/include/scoreboard.h,v
retrieving revision 1.51
diff -u -r1.51 scoreboard.h
--- scoreboard.h9 Feb 2004 20:38:21 - 1.51
+++ scoreboard.h26 Jul 2004 09:33:26 -
@@ -32,6 +32,7 @@
#include apr_thread_proc.h
#include apr_portable.h
#include apr_shm.h
+#include apr_optional.h
/* Scoreboard file, if there is one */
#ifndef DEFAULT_SCOREBOARD
@@ -118,6 +119,7 @@
typedef struct {
int server_limit;
int thread_limit;
+int lb_limit;
ap_scoreboard_e sb_type;
ap_generation_t running_generation;/* the generation of children which
* should still be serving requests. */
@@ -135,6 +137,13 @@
*/
};
+/* stuff which is lb specific */
+typedef struct lb_score lb_score;
+struct lb_score{
+/* TODO: make a real stuct from this */
+unsigned char data[1024];
+};
+
/* Scoreboard is now in 'local' memory, since it isn't updated once created,
* even in forked architectures. Child created-processes (non-fork) will
* set up these indicies into the (possibly relocated) shmem records.
@@ -143,6 +152,7 @@
global_score *global;
process_score *parent;
worker_score **servers;
+lb_score **balancers;
} scoreboard;
typedef struct ap_sb_handle_t ap_sb_handle_t;
@@ -168,6 +178,7 @@
AP_DECLARE(worker_score *) ap_get_scoreboard_worker(int x, int y);
AP_DECLARE(process_score *) ap_get_scoreboard_process(int x);
AP_DECLARE(global_score *) ap_get_scoreboard_global(void);
+AP_DECLARE(lb_score *) ap_get_scoreboard_lb(int child_num, int lb_num);
AP_DECLARE_DATA extern scoreboard *ap_scoreboard_image;
AP_DECLARE_DATA extern const char *ap_scoreboard_fname;
@@ -184,6 +195,13 @@
* @return OK or DECLINE on success; anything else is a error
*/
AP_DECLARE_HOOK(int, pre_mpm, (apr_pool_t *p, ap_scoreboard_e sb_type))
+
+/**
+ * proxy load balancer
+ * @return the number of load balancer workers.
+ */
+APR_DECLARE_OPTIONAL_FN(int, ap_proxy_lb_workers,
+(void));
/* for time_process_request() in http_main.c */
#define START_PREQUEST 1
Index: scoreboard.c
===
RCS file: /home/cvspublic/httpd-2.0/server/scoreboard.c,v
retrieving revision 1.74
diff -u -r1.74 scoreboard.c
--- scoreboard.c9 Feb 2004 20:40:49 - 1.74
+++ scoreboard.c26 Jul 2004 10:02:36 -
@@ -59,12 +59,15 @@
(apr_pool_t *p, ap_scoreboard_e sb_type),
(p, sb_type),OK,DECLINED)
+static APR_OPTIONAL_FN_TYPE(ap_proxy_lb_workers)
+*proxy_lb_workers;
+
struct ap_sb_handle_t {
int child_num;
int thread_num;
};
-static int server_limit, thread_limit;
+static int server_limit, thread_limit, lb_limit;
static apr_size_t scoreboard_size;
/*
@@ -89,9 +92,20 @@
{
ap_mpm_query(AP_MPMQ_HARD_LIMIT_THREADS, thread_limit);
ap_mpm_query(AP_MPMQ_HARD_LIMIT_DAEMONS, server_limit);
+
+if (!proxy_lb_workers)
+proxy_lb_workers = APR_RETRIEVE_OPTIONAL_FN(ap_proxy_lb_workers);
+if (proxy_lb_workers)
+lb_limit = proxy_lb_workers();
+else
+lb_limit = 0;
+
scoreboard_size = sizeof(global_score);
scoreboard_size += sizeof(process_score) * server_limit;
scoreboard_size += sizeof(worker_score) * server_limit * thread_limit;
+if (lb_limit)
+scoreboard_size += sizeof(lb_score) * server_limit * lb_limit;
+
return scoreboard_size;
}
@@ -102,7 +116,8 @@
ap_calc_scoreboard_size();
ap_scoreboard_image =
-calloc(1, sizeof(scoreboard) + server_limit * sizeof(worker_score *));
+calloc(1, sizeof(scoreboard) + server_limit * sizeof(worker_score *) +
+ server_limit * lb_limit * sizeof(lb_score *));
more_storage = shared_score;
ap_scoreboard_image-global = (global_score *)more_storage;
RE: Mod_ajp initial
Henri Gomez wrote: Bill Barker wrote: I'm with Graham on this. Personally, I have very little interest in a mod_ajp module, but I am interested in proxy_ajp, proxy_lb, etc. Of course, since j-t-c has long doubled as j-t-sandbox, this means that I'm +0 for committing your stuff there. Well Mladen has been quick to release this initial work and I suspect it will be faster again to make a valid prototype. Sure thing :-). Now we should know who could works on it ? Of course, no one is forced to participate in development, but everyone is welcome. The only question is do we have enough juice to make it official. AFICT, Remy, Henri and myself are in favor. But frankly I see no reason for someone to object, cause it's open source after all, and it doesn't break nothing that already exists. It will of course produce a lot of reusable code for any preferred framework, that can only be a benefit in long run. Simply speaking we will only have a jk/jk2 functionality in a full-blown optimized Apache2 module. MT. smime.p7s Description: S/MIME cryptographic signature
Re: Mod_ajp initial
Remy Maucherat wrote: The framework itself could be designed in a way which would end up hurting performance. It did happen in Tomcat in the past, and I don't know about mod_proxy since I haven't looked at it, but it could happen. All the framework does is determine that a proxy handler is responsible for servicing the request, and passes control to that proxy handler. Any performance problem will be proxy_ajp's problem. I think you should be more open minded about a possible mod_ajp connector This isn't about being open minded, it's about being consistent through the design of httpd. One of the most important features of mod_ajp, even more important than performance, is usability. If the configuration of mod_ajp is significantly different from the configration of proxy, it just adds confusion to end users. mod_jk is already way too complex to be useful - which is why people are choosing proxy_http over mod_jk, even if mod_jk is faster. On the other side of the fence, we have yet to find out that mod_proxy will fully fit our needs. Then I suggest looking at the mod_proxy source, and learning how it works. This will clear up the apparent confusion that exists between mod_proxy and proxy_http. The key functions are proxy_handler() and the proxy_run_scheme_handler() hook. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
TC 5: Support for multiple Coyote JK-Pools
Am I right, that by design TC 5 only fully supports one Coyote JK pool at the moment? I enabled JMX HTTP adaptor via mx.enabled=true. Obviously org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not only once, but for every Coyote JK pool configured in server.xml. For the second pool I get an exception when starting tomcat (see below). When trying to stop TC, the Coyote HTTP pool is shut down correctly, and one of the two JK pools doesn't listen any more, but the second JK pool still listens and TC does not shut down. Retrying shutdown does not help, the process is still alive. Any plans (or work already done) to refactor JkMain/JkMX for 5.next? Rainer Jung Exception during start: 2004-07-26 12:37:58,929 (main) org.apache.jk.common.JkMX/ERROR: Can't load the MX4J http adapter javax.management.InstanceAlreadyExistsException: Http:name=HttpAdaptor at mx4j.server.MBeanServerImpl.register(MBeanServerImpl.java:1123) at mx4j.server.MBeanServerImpl.registerImpl(MBeanServerImpl.java:1054) at mx4j.server.MBeanServerImpl.registerMBeanImpl(MBeanServerImpl.java:1002) at mx4j.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:978) at org.apache.jk.common.JkMX.registerObject(JkMX.java:314) at org.apache.jk.common.JkMX.loadAdapter(JkMX.java:157) at org.apache.jk.common.JkMX.init(JkMX.java:268) at org.apache.jk.server.JkMain.start(JkMain.java:339) at org.apache.jk.server.JkCoyoteHandler.start(JkCoyoteHandler.java:193) at org.apache.coyote.tomcat5.CoyoteConnector.start(CoyoteConnector.java:1527) at org.apache.catalina.core.StandardService.start(StandardService.java:489) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2313) at org.apache.catalina.startup.Catalina.start(Catalina.java:556) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:284) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:422) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 5: Support for multiple Coyote JK-Pools
Rainer Jung wrote: Am I right, that by design TC 5 only fully supports one Coyote JK pool at the moment? I enabled JMX HTTP adaptor via mx.enabled=true. Obviously org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not only once, but for every Coyote JK pool configured in server.xml. For the second pool I get an exception when starting tomcat (see below). When trying to stop TC, the Coyote HTTP pool is shut down correctly, and one of the two JK pools doesn't listen any more, but the second JK pool still listens and TC does not shut down. Retrying shutdown does not help, the process is still alive. Any plans (or work already done) to refactor JkMain/JkMX for 5.next? Yes: use JDK 1.5 JMX instead of this code. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Graham Leggett wrote: Remy Maucherat wrote: The framework itself could be designed in a way which would end up hurting performance. It did happen in Tomcat in the past, and I don't know about mod_proxy since I haven't looked at it, but it could happen. All the framework does is determine that a proxy handler is responsible for servicing the request, and passes control to that proxy handler. Any performance problem will be proxy_ajp's problem. I think you should be more open minded about a possible mod_ajp connector This isn't about being open minded, it's about being consistent through the design of httpd. One of the most important features of mod_ajp, even more important than performance, is usability. If the configuration of mod_ajp is significantly different from the configration of proxy, it just adds confusion to end users. mod_jk is already way too complex to be useful - which is why people are choosing proxy_http over mod_jk, even if mod_jk is faster. I think very few people are actually using mod_proxy instead of mod_jk. You've got to back your assertion with some kind of numbers, otherwise it's FUD. I disagree with your statements. Performance is first, as long as useability isn't too bad. To give an example, a mod_jk 1.2.x fully rewritten with APR, compiled with Apache, and with better configuration would clearly be useable enough (I think mod_jk 1.2 was actually good enough on many Unix platforms). I'm sure Mladen, Henri and Bill will look thoroughly at mod_proxy, and will try their best to use it, but you really need to relax your position from -1 for your code if it doesn't use mod_proxy. You need to add unless we find good reasons why it wouldn't work for us. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jk 1.2.6 release - need more binaries
Hi to all, For jk 1.2.6 the following binaries are allready available : Windows (ISAPI/JK for AP 1.3.31/JK for AP2 2.0.50) Linux (JK for Fedora Core 2 Apache 2.0.50, for Suse 8.0 Apache 2.0.50 PPC, for Suse 9.1 Apache 2.0) Solaris (JK for Apache 1.3.31 EAPI/STANDARD) iSeries (AS/400 V5R2 and UP) We need macosx and netware, solaris / Apache 2.x Thanks to commiters to upload them to Apache dist directory and don't forget to sign the binaries with you PGP/GPG key. Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContext.java
remm2004/07/26 03:56:55
Modified:catalina/src/share/org/apache/catalina/startup
HostConfig.java ContextConfig.java ExpandWar.java
catalina/src/share/org/apache/catalina/core
StandardContext.java
Log:
- Add logic for avoiding locking on Windows. This takes a very heavy handed
approach, but after trying many other methods, I think it's the
only way to properly address the issue and allow real hot (re)deployment.
- It's disabled by default, and there's a new antiResourceLocking attribute on
Context.
- I think I'll leave in the lighter anti JAR locking code in the CL, but disabled by
default (and with another similar flag on Context). It could
address different needs, and is less intrusive, as the webapp stays where it is.
Revision ChangesPath
1.37 +38 -17
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/HostConfig.java
Index: HostConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/HostConfig.java,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- HostConfig.java 26 Jul 2004 08:09:19 - 1.36
+++ HostConfig.java 26 Jul 2004 10:56:53 - 1.37
@@ -496,15 +496,25 @@
host.addChild(context);
// Add the eventual unpacked WAR and all the resources which
will be
// watched inside it
-if (isWar unpackWARs (context.getDocBase() != null)) {
-File docBase = new File(context.getDocBase());
+if (isWar unpackWARs) {
+String name = null;
+String path = context.getPath();
+if (path.equals()) {
+name = ROOT;
+} else {
+if (path.startsWith(/)) {
+name = path.substring(1);
+} else {
+name = path;
+}
+}
+File docBase = new File(name);
if (!docBase.isAbsolute()) {
-docBase = new File(new File(host.getAppBase()),
-context.getDocBase());
+docBase = new File(new File(host.getAppBase()), name);
}
deployedApp.redeployResources.put(docBase.getAbsolutePath(),
new Long(docBase.lastModified()));
-addWatchedResources(deployedApp, context);
+addWatchedResources(deployedApp, docBase.getAbsolutePath(),
context);
}
} catch (Throwable t) {
log.error(sm.getString(hostConfig.deployDescriptor.error,
@@ -642,14 +652,24 @@
// If we're unpacking WARs, the docBase will be mutated after
// starting the context
if (unpackWARs (context.getDocBase() != null)) {
-File docBase = new File(context.getDocBase());
+String name = null;
+String path = context.getPath();
+if (path.equals()) {
+name = ROOT;
+} else {
+if (path.startsWith(/)) {
+name = path.substring(1);
+} else {
+name = path;
+}
+}
+File docBase = new File(name);
if (!docBase.isAbsolute()) {
-docBase = new File(new File(host.getAppBase()),
-context.getDocBase());
+docBase = new File(new File(host.getAppBase()), name);
}
deployedApp.redeployResources.put(docBase.getAbsolutePath(),
new Long(docBase.lastModified()));
-addWatchedResources(deployedApp, context);
+addWatchedResources(deployedApp, docBase.getAbsolutePath(),
context);
}
} catch (Throwable t) {
log.error(sm.getString(hostConfig.deployJar.error,
@@ -722,7 +742,7 @@
host.addChild(context);
deployedApp.redeployResources.put(dir.getAbsolutePath(),
new Long(dir.lastModified()));
-
RE: [Launcher] release 1.0
Hi, This seems fine. I'm a little surprised Tomcat has been using Launcher all this time without a formal Launcher released ever made, but hey, life is full of surprises right? ;) Let me know if you need help from our side. (Saying that with my Tomcat hat on). Yoav Shapira Millennium Research Informatics -Original Message- From: Dirk Verbeeck [mailto:[EMAIL PROTECTED] Sent: Sunday, July 25, 2004 5:34 PM To: Jakarta Commons Developers List; Tomcat Developers List Cc: Jakarta Commons Users List Subject: [Launcher] release 1.0 Launcher was imported into jakarta commons almost 2 years ago (25 okt 2002) but never had a release. The thing missing was a simple example to get new users started. Alban Peignier contributed this example, I added it to CVS. So we're ready to release IMHO. The site is build using maven, the component (and example) is build using an ant build. dev-build can be found here: http://cvs.apache.org/~dirkv/builds/ Unless somebody see a mayor problem I would like to start the release process for launcher, lets say release target date in 3 weeks. Is this enough review time for everybody? I'm especially looking at the tomcat team as they are the main users. Other RC testers are also invited of cource... (please reply to common-dev) -- Dirk - 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]
default charset for text/*
Hello, In our web-app that runs with Tomcat 4.1.29 we set the content-type to text/xml in a servlet that serves an XML file. The XML encoding normally is UTF-8. We observed that special characters show up wrong in the browser. Packet sniffing revealed that Tomcat changed the content-type to text/xml;charset=ISO-8859-1 which was not the case with earlier Tomcat versions. I looked up the bug database and the mailing list for this behaviour and read that Tomcat behaves like this for alle text/* content types where the charset is mising. To fix this I can change the mime-type-definition in web.xml to text/xml;charset=UTF-8 or add this in my servlet. But If my servlet has to serve ISO-8859-1 XML files that would be also wrong. Should I parse the resource prior to serving it in order to determine the encoding? I cannot find the strong requirement to add the default charset in the HTTP spec. I read a discussion in the list that the JSP spec requires it - but also for a servlet? I think the charset is added by the Coyote connector so from the connector's point of view servlets and JSP-servlets are the same. Doesn't it make sense to omit the default charset for XML files because XML files normally should carry their encoding in the header? Then the browser could get the encoding from there as it was done with earlier Tomcat versions. What is your opionion? Best Regards Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Remy Maucherat wrote: I think very few people are actually using mod_proxy instead of mod_jk. You've got to back your assertion with some kind of numbers, otherwise it's FUD. As do you. The assertion was based on comments on this mailing list, but we've already established that there is a need for the ajp protocol, lets move on. I disagree with your statements. Performance is first, as long as useability isn't too bad. Then we must agree to disagree. In my experience, if something isn't usable, it doesn't get used, so any potential performance advantage is purely theoretical. Lack of usability is one of the biggest failures in many open source projects, and I don't want to see httpd fall into that trap. To give an example, a mod_jk 1.2.x fully rewritten with APR, compiled with Apache, and with better configuration would clearly be useable enough (I think mod_jk 1.2 was actually good enough on many Unix platforms). It would be different to the established configuration method for backend servers, thus causing comments like why does ajp work differently to the rest of the server, and why is the load balancing feature of ajp not available server wide?. I'm sure Mladen, Henri and Bill will look thoroughly at mod_proxy, and will try their best to use it, but you really need to relax your position from -1 for your code if it doesn't use mod_proxy. You need to add unless we find good reasons why it wouldn't work for us. httpd exists for the use of end users, not for the private use of just the people you listed. If somebody is going to the effort of creating a module specifically for httpd v2.0, then I don't see why they wouldn't go to the effort of making it fit into the established framework properly. I think _you_ need to do some research into mod_proxy, how it is designed and exactly how it works before making statements about it's performance. By testing the mod_proxy_http module, and then making statements about mod_proxy (a totally different module) shows that you don't know how the proxy framework works. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: jk 1.2.6 release - need more binaries
Henri Gomez wrote: Hi to all, For jk 1.2.6 the following binaries are allready available : Windows (ISAPI/JK for AP 1.3.31/JK for AP2 2.0.50) Linux (JK for Fedora Core 2 Apache 2.0.50, for Suse 8.0 Apache 2.0.50 PPC, for Suse 9.1 Apache 2.0) Solaris (JK for Apache 1.3.31 EAPI/STANDARD) iSeries (AS/400 V5R2 and UP) We need macosx and netware, solaris / Apache 2.x I have done the solaris / Apache 2.x (with native compiler). Thanks to commiters to upload them to Apache dist directory and don't forget to sign the binaries with you PGP/GPG key. Regards - 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: Mod_ajp initial
Graham Leggett wrote: Remy Maucherat wrote: I think very few people are actually using mod_proxy instead of mod_jk. You've got to back your assertion with some kind of numbers, otherwise it's FUD. As do you. The assertion was based on comments on this mailing list, but we've already established that there is a need for the ajp protocol, lets move on. I disagree with your statements. Performance is first, as long as useability isn't too bad. Then we must agree to disagree. In my experience, if something isn't usable, it doesn't get used, so any potential performance advantage is purely theoretical. Lack of usability is one of the biggest failures in many open source projects, and I don't want to see httpd fall into that trap. Peace on ASF :) mod_jk is used on many productions sites. From my experience, admins who use jk are people who are experienced with Tomcat and as such trust jk and get habbits with its configuration. Admins using mod_proxy to link Apache to Tomcat are those who are more confortable with HTTPD standard modules. Up to Coyote, Tomcat HTTP stack was very slow and jk was mandatory for speed and stability. Now we have the choice even if jk is still faster than mod_proxy and proxy_http, but I'm sure than when proxy_http will be using HTTP connections pool the difference will be minimal. And I'm sure than Graham and others will boost mod_proxy+proxy_http :) To give an example, a mod_jk 1.2.x fully rewritten with APR, compiled with Apache, and with better configuration would clearly be useable enough (I think mod_jk 1.2 was actually good enough on many Unix platforms). It would be different to the established configuration method for backend servers, thus causing comments like why does ajp work differently to the rest of the server, and why is the load balancing feature of ajp not available server wide?. well mod_ajp will probably goes a bit farther than mod_proxy + proxy_ajp since mod_proxy will allways relay static configuration, ie map some knowns URL to knowns Tomcat. The next step is to be able to update URI Mapping and Tomcat defs in real, to avoid a restart of a production server. I know real productions case where the HTTPD server COULDN'T and SHOULDN'T be restarted and when you add another Tomcat to the cluster, for example to help support an increase of load. mod_ajp will help these admins to have a configurable non-stop cluster 'controller'. But for those without this requirement mod_proxy + proxy_ajp will be a perfect combination. I'm sure Mladen, Henri and Bill will look thoroughly at mod_proxy, and will try their best to use it, but you really need to relax your position from -1 for your code if it doesn't use mod_proxy. You need to add unless we find good reasons why it wouldn't work for us. httpd exists for the use of end users, not for the private use of just the people you listed. If somebody is going to the effort of creating a module specifically for httpd v2.0, then I don't see why they wouldn't go to the effort of making it fit into the established framework properly. Tomcat also exist for the use of end users. All ASF products are made for users, not for hackers purposes. Read my statement about dynamic configuration and you'll see it's something needed for admins. Part of my pay job is managing Apache HTTPD and Tomcat servers and the dynamic update is really something needed, because I don't want to see one day commercial products installed since Apache HTTPD and Tomcats couldn't sastify this need. Yes, as many here I'd want to use ASF products, for real productions situations, I'm not a hacker. I think _you_ need to do some research into mod_proxy, how it is designed and exactly how it works before making statements about it's performance. By testing the mod_proxy_http module, and then making statements about mod_proxy (a totally different module) shows that you don't know how the proxy framework works. We understand that mod_proxy is a kind of server in HTTPD, I also track new-httpd list and remember the mod_proxy genese, the pros and cons even in HTTPD commiters. Mladen, Graham, Bill, Henri, Remy, we're all ASF commiters and as such we should works together to make ASF products better. The only way is to learn from each others since there is also great commiters in jakarta. BTW, Mladen, who known very well Apache 2.0 allready send some comments, fixes and patches for mod_proxy and proxy_http. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Henri Gomez wrote: Peace on ASF :) Indeed :) well mod_ajp will probably goes a bit farther than mod_proxy + proxy_ajp since mod_proxy will allways relay static configuration, ie map some knowns URL to knowns Tomcat. Why would mod_proxy always rely on a static configuration? Don't forget that a lot of the features of mod_jk (the dynamic stuff especially) would be very much welcomed if they were added to the proxy framework. Don't think that the proxy code is cast in stone - it is not. The first patch for the scoreboard has already been contributed, and I'm waiting for a lack of objection, then the patch is going into httpd v2.1 with a vote for a backport to v2.0. Being able to dynamically configure backends other than just tomcat would be an extremely useful feature for people who use mod_perl, or CGI, or other application servers. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
DO NOT REPLY [Bug 30322] New: - Jsp's source directory in task Jasper2 for ant
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=30322.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=30322
Jsp's source directory in task Jasper2 for ant
Summary: Jsp's source directory in task Jasper2 for ant
Product: Tomcat 5
Version: 5.0.27
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
When I use the Jasper2 task (ant 1.6.2) as specify in documentation,
I can't specify the directory of the .jsp file. He takes all files .jsp in
the uriroot.
I have a problem this comportement for 2 raisons :
1) Files .jsp in directory CVS don't be compiled ! (sometimes these files are
not valide).
2) I have several directory containing Jsp file, I would like compile only
directory.
I have change the JspC.java : add a new paramter in task Ant : srcDic.
What do you thing about my solution ?
Elisabeth J.
Index: JspC.java
===
RCS file: /home/cvspublic/jakarta-tomcat-
jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
retrieving revision 1.80
diff -w -B -b -r1.80 JspC.java
141a142
private String srcDir;
518a520,528
// M2
/**
M2 : Spécifie le répertoire Source des fichiers Jsp
*/
public void setSrcDir(String Dir) {
srcDir=Dir;
}
// M2
830a841,844
// M1 : Il faut ignorer les répertoires CVS
String cvs = files[i].substring(files[i].lastIndexOf
('/') +1);
if (!cvs.equalsIgnoreCase(CVS))
{
831a846,847
}
// M1
875c891,895
scanFiles( new File( uriRoot ));
---
// M2 : Spécification du répertoire source
if (srcDir == null) {srcDir=uriRoot;}
else {if (!(new File(srcDir)).isAbsolute())
{srcDir=uriRoot+/+srcDir;}}
scanFiles( new File( srcDir ));
// M2
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 5: Support for multiple Coyote JK-Pools
Remy Maucherat wrote: Rainer Jung wrote: Am I right, that by design TC 5 only fully supports one Coyote JK pool at the moment? I enabled JMX HTTP adaptor via mx.enabled=true. Obviously org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not only once, but for every Coyote JK pool configured in server.xml. For the second pool I get an exception when starting tomcat (see below). When trying to stop TC, the Coyote HTTP pool is shut down correctly, and one of the two JK pools doesn't listen any more, but the second JK pool still listens and TC does not shut down. Retrying shutdown does not help, the process is still alive. Any plans (or work already done) to refactor JkMain/JkMX for 5.next? Yes: use JDK 1.5 JMX instead of this code. Are we going to switch to JDK1.5 ??? I missed this one. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Graham Leggett wrote: Henri Gomez wrote: Peace on ASF :) Indeed :) well mod_ajp will probably goes a bit farther than mod_proxy + proxy_ajp since mod_proxy will allways relay static configuration, ie map some knowns URL to knowns Tomcat. Why would mod_proxy always rely on a static configuration? Don't forget that a lot of the features of mod_jk (the dynamic stuff especially) would be very much welcomed if they were added to the proxy framework. Don't think that the proxy code is cast in stone - it is not. The first patch for the scoreboard has already been contributed, and I'm waiting for a lack of objection, then the patch is going into httpd v2.1 with a vote for a backport to v2.0. Being able to dynamically configure backends other than just tomcat would be an extremely useful feature for people who use mod_perl, or CGI, or other application servers. Well Tomcat's commiters, I think we found another friend on HTTPD-DEV :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Mladen Turk wrote: Of course, no one is forced to participate in development, but everyone is welcome. The only question is do we have enough juice to make it official. AFICT, Remy, Henri and myself are in favor. But frankly I see no reason for someone to object, cause it's open source after all, and it doesn't break nothing that already exists. I'm not in favor, quite the contrary. And I thing there are reasons to object - doesn't break anthing that exists is not the only criteria used in apache. Is it the best solution ? can be used sometimes. I think mod_proxy + ajp + enhancements might be the right solution. It seems httpd people are willing to accept this into apache2, where it should be - and it seems very likely ( and reasonable ) they'll not accept another module that does almost the same thing ( but with different config and codebase ). I'm also not convinced that mod_ajp had been properly designed - I hear Henri mentioning configurable non stop cluster and no restart, yet dynamic configuration was previously discarded by other people. And the config format suggests that little consideration was given to this - even the workers are configured in httpd.conf in a way that makes it hard to reconfigure with restarting apache. If dynamic reconfiguration ( even the minimal workers reconfig ) is on the list of features - adding it later will make the code as messy as mod_jk1 and 2. And if dynamic config is not on the list - then it won't solve the problem for people who really need apache+tomcat, i.e. many large sites with uptime requirements. Why confuse the people with yet another connector - and what hope can we have it will not have the same fate as mod_webapp ? In any case - even if I'm no longer a very active tomcat committer, I think I can still -1 something that doesn't have a clear set of requirements, doesn't have a clear design that is able to support those features, doesn't have a configuration that is easy ( and by that I mean familiar for admins ), etc. You can ignore my vote if you want, but I'm pretty sure I am right. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30322] - Jsp's source directory in task Jasper2 for ant
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30322. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30322 Jsp's source directory in task Jasper2 for ant [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 15:06 --- Use the jspFiles attribute to compiled specific files. The javadocs have more info. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mod_ajp initial
Costin Manolache wrote: Mladen Turk wrote: Of course, no one is forced to participate in development, but everyone is welcome. The only question is do we have enough juice to make it official. AFICT, Remy, Henri and myself are in favor. But frankly I see no reason for someone to object, cause it's open source after all, and it doesn't break nothing that already exists. I'm not in favor, quite the contrary. And I thing there are reasons to object - doesn't break anthing that exists is not the only criteria used in apache. Is it the best solution ? can be used sometimes. I must disagree with you. There has been previous talks about 'wasting resources', that looks just like some corporate manager would talk. You can not stop people seeking other solutions, trying to build something better. It's the compete opposition of what IMO ASF stands for. If I make a design flaw, and the entire project gets unusable, it will make it just something like mod_java, mod_warp, mod_jk and mod_jk2 are... Dead. Nobody will get hanged for that. In any case - even if I'm no longer a very active tomcat committer, I think I can still -1 something that doesn't have a clear set of requirements, doesn't have a clear design that is able to support those features, doesn't have a configuration that is easy ( and by that I mean familiar for admins ), etc. You can ignore my vote if you want, but I'm pretty sure I am right. What about free spirit, and creative mess, that produced something like Apache2 and Tomcat. Are we going to need to have a full set of requirements and marketing analysis for each patch we make? Thing you've gone too far :( Regards, MT. smime.p7s Description: S/MIME cryptographic signature
DO NOT REPLY [Bug 30324] New: - ERROR [JkCoyoteHandler] Error in action code
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30324. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30324 ERROR [JkCoyoteHandler] Error in action code Summary: ERROR [JkCoyoteHandler] Error in action code Product: Tomcat 4 Version: 4.1.0 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] keep getting this stack trace dump whenever i crank up catilina.. 10:40:21,013 ERROR [JkCoyoteHandler] Error in action code java.net.SocketException: Software caused connection abort: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:457) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:654) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:435) at org.apache.coyote.Response.action(Response.java:226) at org.apache.coyote.Response.finish(Response.java:348) at org.apache.coyote.tomcat4.OutputBuffer.close(OutputBuffer.java:324) at org.apache.coyote.tomcat4.CoyoteResponse.finishResponse (CoyoteResponse.java:486) at org.apache.coyote.tomcat4.CoyoteAdapter.service (CoyoteAdapter.java:198) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:309) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:387) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:673) at org.apache.jk.common.ChannelSocket.processConnection (ChannelSocket.java:615) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:786) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:677) at java.lang.Thread.run(Thread.java:534) 10:40:21,043 ERROR [JkCoyoteHandler] Error in action code java.net.SocketException: Software caused connection abort: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:457) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:654) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:435) at org.apache.coyote.Response.action(Response.java:226) at org.apache.coyote.Response.finish(Response.java:348) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:314) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:387) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:673) at org.apache.jk.common.ChannelSocket.processConnection (ChannelSocket.java:615) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:786) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:677) at java.lang.Thread.run(Thread.java:534) 10:40:21,043 ERROR [ChannelSocket] Error, processing connection java.net.SocketException: Software caused connection abort: recv failed at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.BufferedInputStream.fill(BufferedInputStream.java:183) at java.io.BufferedInputStream.read1(BufferedInputStream.java:222) at java.io.BufferedInputStream.read(BufferedInputStream.java:277) at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:548) at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java:486) at org.apache.jk.common.ChannelSocket.processConnection (ChannelSocket.java:603) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:786) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:677) at java.lang.Thread.run(Thread.java:534) 10:40:21,423 ERROR [JkCoyoteHandler] Error in action code java.net.SocketException: Software caused connection abort: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:457) at
DO NOT REPLY [Bug 30324] - ERROR [JkCoyoteHandler] Error in action code
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30324. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30324 ERROR [JkCoyoteHandler] Error in action code --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 15:29 --- You might want to try a more recent version of tomcat. 4.1.0 is very old and the relevant code has changed numerous times since then. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Costin Manolache wrote: Mladen Turk wrote: Of course, no one is forced to participate in development, but everyone is welcome. The only question is do we have enough juice to make it official. AFICT, Remy, Henri and myself are in favor. But frankly I see no reason for someone to object, cause it's open source after all, and it doesn't break nothing that already exists. I'm not in favor, quite the contrary. And I thing there are reasons to object - doesn't break anthing that exists is not the only criteria used in apache. Is it the best solution ? can be used sometimes. Well I've got more than one reason to object to current jk2 and jk. jk works but the code is a huge spaghetti. jk2 didn't works well and we could consider it dead before it even reach production level. It's not a Henri/Mladen/Remy decision but what Apache admins says about jk2 here and outside ASF. I think mod_proxy + ajp + enhancements might be the right solution. It seems httpd people are willing to accept this into apache2, where it should be - and it seems very likely ( and reasonable ) they'll not accept another module that does almost the same thing ( but with different config and codebase ). Mladen has allready provided some update for HTTPD-DEV and I'm confident than Graham and Mladen will works together to improve mod_proxy to make in fine something as fast as the current mod_jk. I'm also not convinced that mod_ajp had been properly designed - I hear Henri mentioning configurable non stop cluster and no restart, yet dynamic configuration was previously discarded by other people. And the config format suggests that little consideration was given to this - even the workers are configured in httpd.conf in a way that makes it hard to reconfigure with restarting apache. If dynamic reconfiguration ( even the minimal workers reconfig ) is on the list of features - adding it later will make the code as messy as mod_jk1 and 2. Well who said the Worker/Instance will have to be hardcoded in httpd.conf ? I said that some known Tomcat instances, Remy asked us to avoid the old jk/jk2 naming, are set in Apache 2 by default, but nothing prevent us to add new instance dynamically, via ajp_status or mod_status or whatever (may be even via AJP/1.4). And if dynamic config is not on the list - then it won't solve the problem for people who really need apache+tomcat, i.e. many large sites with uptime requirements. Why confuse the people with yet another connector - and what hope can we have it will not have the same fate as mod_webapp ? I'm handling sites requiring this kind of requirement and it's high on my mod_ajp features wish list. When you operate sites which works 24/24 and 7/7 and need to add horse power, it's a nightmare to have to wait some period in the night to make the Apache server update and restart. Also admins may want to add some power for a short period of time, so adding and removing such instances should be easy and quick. In any case - even if I'm no longer a very active tomcat committer, I think I can still -1 something that doesn't have a clear set of requirements, doesn't have a clear design that is able to support those features, doesn't have a configuration that is easy ( and by that I mean familiar for admins ), etc. You can ignore my vote if you want, but I'm pretty sure I am right. Well I'd like to resume the mod_ajp goal : - an APR/Apache 2 specific module (no more mess with #ifdef for 30 differents OS, we're in 2004). - extract ajp stuff and put it in an ajp library, which could be used outside within the Apache 2.0 module, used by proxy_ajp and of course in others applications, ie ajp-bench. - Study what has been done in mod_proxy to follow the start of art in Apache 2.x dev and make sure we could works with others AP2 modules. - Add/Remove/Update of Tomcat instances, and allow to attach/map them to URI and LB instances. Costin will probably mention JMX/CMX support, but I think this is something so important that it should be in HTTPD-dev and not only in mod_ajp. Thanks to comments - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29831] - Support for boolean property in bean factory
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29831. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29831 Support for boolean property in bean factory [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 15:40 --- Done, thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Can someone please unsubscribe me from this list? I have sent about 20 email to unsubscribe and I'm still recieving them. THanks Mike Currie Senior Web Developer New Century Mortgage Direct 949 743 7037 Mobile 949 279 4358 Fax 866 281 0360 This electronic message transmission contains information from New Century which may be confidential or privileged. This information is intended for the use of the individuals or entity named in the message. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this transmission is strictly prohibited. If you have received this electronic transmission in error, please notify us immediately by telephone and delete the message from your system. Thank you. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, July 26, 2004 8:35 AM To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml yoavs 2004/07/26 08:34:32 Modified:catalina/src/bin setclasspath.bat webapps/docs changelog.xml Log: Addressed Bugzilla 29826. Revision ChangesPath 1.7 +2 -2 jakarta-tomcat-catalina/catalina/src/bin/setclasspath.bat Index: setclasspath.bat === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/setclasspath.bat,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- setclasspath.bat 12 Feb 2004 21:38:56 - 1.6 +++ setclasspath.bat 26 Jul 2004 15:34:31 - 1.7 @@ -52,6 +52,6 @@ goto end :exit -exit +exit /b 1 :end 1.76 +3 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.75 retrieving revision 1.76 diff -u -r1.75 -r1.76 --- changelog.xml 23 Jul 2004 14:13:41 - 1.75 +++ changelog.xml 26 Jul 2004 15:34:31 - 1.76 @@ -29,6 +29,9 @@ fix bug30245/bug: Corrected Connector documentation to list address as a common attribute. (yoavs) /fix + fix +bug29826/bug: Modified setclasspath.bat exit code to 1. (yoavs) + /fix /changelog /subsection - 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 29826] - Installation always exits with an error code.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29826. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29826 Installation always exits with an error code. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 15:37 --- Thank you for reporting this bug and posting patches. I've applied the setclasspath exit code patch. The catalina.bat %current_dir% one was already applied in 5.0.26 or 5.0.27, so no action needed there. In the future, if possible post diff patches rather than the full file. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 5: Support for multiple Coyote JK-Pools
Costin Manolache wrote: Remy Maucherat wrote: Rainer Jung wrote: Am I right, that by design TC 5 only fully supports one Coyote JK pool at the moment? I enabled JMX HTTP adaptor via mx.enabled=true. Obviously org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not only once, but for every Coyote JK pool configured in server.xml. For the second pool I get an exception when starting tomcat (see below). When trying to stop TC, the Coyote HTTP pool is shut down correctly, and one of the two JK pools doesn't listen any more, but the second JK pool still listens and TC does not shut down. Retrying shutdown does not help, the process is still alive. Any plans (or work already done) to refactor JkMain/JkMX for 5.next? Yes: use JDK 1.5 JMX instead of this code. Are we going to switch to JDK1.5 ??? I missed this one. Actually, I posted that we could consider switching to JDK 1.5, yes (I do really like that JDK). The idea is that I'm tweaking the API, so I would use the new stuff when rewriting code. I don't think it'll happen in the end, since not many people seem to be in favor of it. Here, I was mentioning that using JDK 1.5 would be a workaround (as the connector registration moves out of the JVM). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
yoavs 2004/07/26 08:39:13
Modified:catalina/src/share/org/apache/naming/factory
BeanFactory.java
webapps/docs changelog.xml
Log:
Addressed Bugzilla 29831.
Revision ChangesPath
1.3 +3 -0
jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/factory/BeanFactory.java
Index: BeanFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/factory/BeanFactory.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- BeanFactory.java 27 Feb 2004 14:58:54 - 1.2
+++ BeanFactory.java 26 Jul 2004 15:39:13 - 1.3
@@ -186,6 +186,9 @@
} else if (propType.equals(Double.class)
|| propType.equals(double.class)) {
valueArray[0] = new Double(value);
+} else if (propType.equals(Boolean.class)
+ || propType.equals(boolean.class)) {
+valueArray[0] = new Boolean(value);
} else {
throw new NamingException
(String conversion for property type '
1.77 +5 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml
Index: changelog.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
retrieving revision 1.76
retrieving revision 1.77
diff -u -r1.76 -r1.77
--- changelog.xml 26 Jul 2004 15:34:31 - 1.76
+++ changelog.xml 26 Jul 2004 15:39:13 - 1.77
@@ -36,6 +36,11 @@
/subsection
subsection name=Catalina
+changelog
+ fix
+bug29831/bug: Added support for Boolean property to BeanFactory. (yoavs)
+ /fix
+/changelog
/subsection
subsection name=Coyote
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java WebappLoader.java
remm2004/07/26 08:52:17
Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java WebappLoader.java
Log:
- Update to use a flag for the anti JAR locking code. It isn't as foolproof as the
other one, since you can't just delete a WAR or expanded
folder to undeploy (on Windows, of course).
- I think the two flags together will cover all the needs.
Revision ChangesPath
1.40 +37 -12
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
Index: WebappClassLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- WebappClassLoader.java23 Jul 2004 22:40:11 - 1.39
+++ WebappClassLoader.java26 Jul 2004 15:52:17 - 1.40
@@ -160,6 +160,13 @@
protected static final StringManager sm =
StringManager.getManager(Constants.Package);
+
+/**
+ * Use anti JAR locking code, which does URL rerouting when accessing
+ * resources.
+ */
+boolean antiJARLocking = false;
+
// --- Constructors
@@ -405,6 +412,22 @@
/**
+ * @return Returns the antiJARLocking.
+ */
+public boolean getAntiJARLocking() {
+return antiJARLocking;
+}
+
+
+/**
+ * @param antiJARLocking The antiJARLocking to set.
+ */
+public void setAntiJARLocking(boolean antiJARLocking) {
+this.antiJARLocking = antiJARLocking;
+}
+
+
+/**
* If there is a Java SecurityManager create a read FilePermission
* or JndiPermission for the file directory path.
*
@@ -1027,17 +1050,19 @@
if (url != null) {
// Locating the repository for special handling in the case
// of a JAR
-ResourceEntry entry = (ResourceEntry) resourceEntries.get(name);
-try {
-String repository = entry.codeBase.toString();
-if ((repository.endsWith(.jar))
- (!(name.endsWith(.class {
-// Copy binary content to the work directory if not present
-File resourceFile = new File(loaderDir, name);
-url = resourceFile.toURL();
+if (antiJARLocking) {
+ResourceEntry entry = (ResourceEntry) resourceEntries.get(name);
+try {
+String repository = entry.codeBase.toString();
+if ((repository.endsWith(.jar))
+ (!(name.endsWith(.class {
+// Copy binary content to the work directory if not present
+File resourceFile = new File(loaderDir, name);
+url = resourceFile.toURL();
+}
+} catch (Exception e) {
+// Ignore
}
-} catch (Exception e) {
-// Ignore
}
if (log.isDebugEnabled())
log.debug( -- Returning ' + url.toString() + ');
@@ -1766,7 +1791,7 @@
}
// Extract resources contained in JAR to the workdir
-if (!(path.endsWith(.class))) {
+if (antiJARLocking !(path.endsWith(.class))) {
byte[] buf = new byte[1024];
File resourceFile = new File
(loaderDir, jarEntry.getName());
1.31 +3 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappLoader.java
Index: WebappLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappLoader.java,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- WebappLoader.java 23 Jul 2004 22:40:11 - 1.30
+++ WebappLoader.java 26 Jul 2004 15:52:17 - 1.31
@@ -645,6 +645,8 @@
classLoader = createClassLoader();
classLoader.setResources(container.getResources());
classLoader.setDelegate(this.delegate);
+if (container instanceof StandardContext)
+classLoader.setAntiJARLocking(((StandardContext)
container).getAntiJARLocking());
for (int i = 0; i repositories.length; i++) {
classLoader.addRepository(repositories[i]);
DO NOT REPLY [Bug 30274] - Servlet.service() for servlet jsp threw exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30274. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30274 Servlet.service() for servlet jsp threw exception --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 15:54 --- Well, seeing as how the exception is in your code, maybe you can post upload.jsp? As an aside, you might want to use the mailing list for bug discussions and assitance, as they are more widely and frequently read than the Bugzilla issues. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup ContextConfig.java
remm2004/07/26 08:54:39
Modified:catalina/src/share/org/apache/catalina/startup
ContextConfig.java
Log:
- When using the antiLocking flag, attempt to remove as much of the temp files when
stopping.
- As it was the case before, remove the work dir when undeploying.
Revision ChangesPath
1.50 +28 -3
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
Index: ContextConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
retrieving revision 1.49
retrieving revision 1.50
diff -u -r1.49 -r1.50
--- ContextConfig.java26 Jul 2004 10:56:54 - 1.49
+++ ContextConfig.java26 Jul 2004 15:54:38 - 1.50
@@ -103,6 +103,12 @@
*/
protected SAXParseException parseException = null;
+
+/**
+ * Original docBase.
+ */
+protected String originalDocBase = null;
+
/**
* The string resources for this package.
@@ -753,6 +759,11 @@
String docBase = context.getDocBase();
if (docBase == null)
return;
+if (originalDocBase == null) {
+originalDocBase = docBase;
+} else {
+docBase = originalDocBase;
+}
File docBaseFile = new File(docBase);
if (!docBaseFile.isAbsolute()) {
docBaseFile = new File(appBase, docBase);
@@ -773,7 +784,7 @@
}
File file = null;
-if (context.getDocBase().toLowerCase().endsWith(.war)) {
+if (docBase.toLowerCase().endsWith(.war)) {
file = new File(System.getProperty(java.io.tmpdir),
deploymentCount++ + - + docBase + .war);
} else {
@@ -1057,6 +1068,18 @@
context.removeWrapperListener(wrapperListeners[i]);
}
+// Remove (partially) folders and files created by antiLocking
+Host host = (Host) context.getParent();
+String appBase = host.getAppBase();
+String docBase = context.getDocBase();
+if ((docBase != null) (originalDocBase != null)) {
+File docBaseFile = new File(docBase);
+if (!docBaseFile.isAbsolute()) {
+docBaseFile = new File(appBase, docBase);
+}
+ExpandWar.delete(docBaseFile);
+}
+
ok = true;
}
@@ -1069,7 +1092,9 @@
// Called from StandardContext.destroy()
if (log.isDebugEnabled())
log.debug(sm.getString(contextConfig.destroy));
-
+String workDir = ((StandardContext) context).getWorkDir();
+if (workDir != null)
+ExpandWar.delete(new File(workDir));
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30279] - allowLinking attribute value is not preserved or ignored after context is reloaded
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30279. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30279 allowLinking attribute value is not preserved or ignored after context is reloaded [EMAIL PROTECTED] changed: What|Removed |Added Summary|allowLinking attribute value|allowLinking attribute value |is not preserved or ignored |is not preserved or ignored |after context is reloaded |after context is reloaded --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 15:56 --- You added what to server.xml? There's nothing following your first paragraph. Try 5.0.27 and update your bug report if it still fails in 5.0.27. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Dynamic updates and Apache v2.0
Hi all, I am starting a new thread for this, as it seems to be an important killer-app feature for any httpd v2.0 integration. People have said the config should be dynamically configurable - which part of the config should be dynamically configurable? In other words, would any of these senarios make sense: - A potential pool of servers (IP address/port combinations) is defined, and httpd gracefully handles the case where a server is missing. Adding a new server is as simple as starting it up on one of the predefined ip/ports combinations. An admin might configure an entire subnet as tomcat servers, and then add and remove backend servers at will. Easy to do, but a bit limiting. - httpd is informed via a special URL of updates to the servers on the backend, a bit like the management app in tomcat. This functionality might grow to being available to the whole httpd config. Being a URL, it would be pretected by standard mechanisms like SSL and basic authentication. Powerful, but a big change that will likely only appear in httpd v2.1 or v2.2. - httpd polls the backend servers using the OPTIONS method (as was recommended recently). In the info returned, httpd learns of the intended weighting of the servers, whether a server needs to be removed gracefully from the pool, or whether other servers have been added to the pool and should be included in the config. Here httpd needs only to be told about just one backend server, which will seed httpd with info about all the other servers. Out of the above three the third option seems to make the most sense. It's not very obtrusive, it can be used with backends other than tomcat. Actually updating the server list and weightings can be done via the tomcat management app, which already exists now (as opposed to a theoritical management app for httpd). Thoughts? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Please take me off the list.
Hi, Why am I included on this list? Please remove me from the list. Thanks. colin - 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: Mod_ajp initial
Henri Gomez wrote: Costin Manolache wrote: Mladen Turk wrote: Of course, no one is forced to participate in development, but everyone is welcome. The only question is do we have enough juice to make it official. AFICT, Remy, Henri and myself are in favor. But frankly I see no reason for someone to object, cause it's open source after all, and it doesn't break nothing that already exists. I'm not in favor, quite the contrary. And I thing there are reasons to object - doesn't break anthing that exists is not the only criteria used in apache. Is it the best solution ? can be used sometimes. Well I've got more than one reason to object to current jk2 and jk. jk works but the code is a huge spaghetti. jk2 didn't works well and we could consider it dead before it even reach production level. It's not a Henri/Mladen/Remy decision but what Apache admins says about jk2 here and outside ASF. I think mod_proxy + ajp + enhancements might be the right solution. It seems httpd people are willing to accept this into apache2, where it should be - and it seems very likely ( and reasonable ) they'll not accept another module that does almost the same thing ( but with different config and codebase ). Mladen has allready provided some update for HTTPD-DEV and I'm confident than Graham and Mladen will works together to improve mod_proxy to make in fine something as fast as the current mod_jk. I'm also not convinced that mod_ajp had been properly designed - I hear Henri mentioning configurable non stop cluster and no restart, yet dynamic configuration was previously discarded by other people. And the config format suggests that little consideration was given to this - even the workers are configured in httpd.conf in a way that makes it hard to reconfigure with restarting apache. If dynamic reconfiguration ( even the minimal workers reconfig ) is on the list of features - adding it later will make the code as messy as mod_jk1 and 2. Well who said the Worker/Instance will have to be hardcoded in httpd.conf ? I said that some known Tomcat instances, Remy asked us to avoid the old jk/jk2 naming, are set in Apache 2 by default, but nothing prevent us to add new instance dynamically, via ajp_status or mod_status or whatever (may be even via AJP/1.4). And if dynamic config is not on the list - then it won't solve the problem for people who really need apache+tomcat, i.e. many large sites with uptime requirements. Why confuse the people with yet another connector - and what hope can we have it will not have the same fate as mod_webapp ? I'm handling sites requiring this kind of requirement and it's high on my mod_ajp features wish list. When you operate sites which works 24/24 and 7/7 and need to add horse power, it's a nightmare to have to wait some period in the night to make the Apache server update and restart. Also admins may want to add some power for a short period of time, so adding and removing such instances should be easy and quick. In any case - even if I'm no longer a very active tomcat committer, I think I can still -1 something that doesn't have a clear set of requirements, doesn't have a clear design that is able to support those features, doesn't have a configuration that is easy ( and by that I mean familiar for admins ), etc. You can ignore my vote if you want, but I'm pretty sure I am right. Well I'd like to resume the mod_ajp goal : - an APR/Apache 2 specific module (no more mess with #ifdef for 30 differents OS, we're in 2004). - extract ajp stuff and put it in an ajp library, which could be used outside within the Apache 2.0 module, used by proxy_ajp and of course in others applications, ie ajp-bench. - Study what has been done in mod_proxy to follow the start of art in Apache 2.x dev and make sure we could works with others AP2 modules. - Add/Remove/Update of Tomcat instances, and allow to attach/map them to URI and LB instances. Costin will probably mention JMX/CMX support, but I think this is something so important that it should be in HTTPD-dev and not only in mod_ajp. Thanks to comments We have noted that mod_proxy + mod_proxy_http are slow compared with mod_jk. I think that the next step should be to try to find why instead writting a new modules. May be a quick hacked mod_proxy_ajp to replace mod_proxy_http is the first step. Note that I am a bit reluctant to start a new module because I already had lost a lot of time in mod_webapp ;-( - 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: Mod_ajp initial
Mladen Turk wrote: If I make a design flaw, and the entire project gets unusable, it will make it just something like mod_java, mod_warp, mod_jk and mod_jk2 are... Dead. Nobody will get hanged for that. Some code is always better than no code - at best, the code will be good enough to fit the needs, and will end up in wide use. At worst, the writers will say we learned some lessons from this and try again. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
DO NOT REPLY [Bug 30314] - Review new HostConfig and add something
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30314. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30314 Review new HostConfig and add something [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 16:41 --- I committed some updated code, which seems to work, more or less. It's not done yet, but it's getting there. Some of your suggestions were good, thanks (but you should post them on tomcat-dev, probably). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30279] - allowLinking attribute value is not preserved or ignored after context is reloaded
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30279. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30279 allowLinking attribute value is not preserved or ignored after context is reloaded --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 16:32 --- The following was added in server.xml Context path=/myApp docBase=myApp debug=0 reloadable=true crossContext=true Resources className=org.apache.naming.resources.FileDirContext allowLinking=true / /Context Still symlink was not possible. If there is no prob with 5.0.24, could it be because I have installed Tomcat as root on my linux desktop? Regards Mahesh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30314] - Review new HostConfig and add something
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30314. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30314 Review new HostConfig and add something --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 16:47 --- Hello Remy, you mean that post better patches and comments at the tomdev list? regards Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30314] - Review new HostConfig and add something
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30314. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30314 Review new HostConfig and add something --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 16:58 --- Yes, to talk about development issues, I think it's better. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mod_ajp initial
Graham Leggett wrote: Mladen Turk wrote: If I make a design flaw, and the entire project gets unusable, it will make it just something like mod_java, mod_warp, mod_jk and mod_jk2 are... Dead. Nobody will get hanged for that. Some code is always better than no code - at best, the code will be good enough to fit the needs, and will end up in wide use. At worst, the writers will say we learned some lessons from this and try again. True. A week or so before, none of us considered mod_proxy to be a good candidate for ajp protocol. The main reason was presumed 'closeness' of httpd developers to consider something like that. But, fortunately the discussion has led to something that might have a great potential. If we find enough support in httpd developers to accept the needed changes so we can build something usable and powerful enough to fulfill our (and presumably the users) needs, both mod_ajp and similar initiatives will be useless. There is also a question about 2.0 support, and that is the main reason for concerns. If all the changes made to make the mod_proxy 'ajp enabled' gets back propagated to 2.0 then we'll have all that is needed. Other option is to either write something from jk/jk2 in a short period of time (mod_ajp) that will fill in the gap of transition from 2.0 to 2.1, or still hanging around jk and jk2. In second case, I see the mod_ajp as a base for 2.0 users that will ease them to transition to mod_proxy in 2.1. That means that we will try to follow both the design and configuration look and feel the mod_proxy will use. And finally, when 2.1 gets the majority, the mod_ajp will be put in maintaining mode (read; shot to be dead :) MT. smime.p7s Description: S/MIME cryptographic signature
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
billbarker2004/07/26 10:04:04 Modified:webapps/docs changelog.xml Log: Fix version #. What ever the next version is that is released from here, it is not going to be called 5.0.x. Revision ChangesPath 1.78 +1 -1 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.77 retrieving revision 1.78 diff -u -r1.77 -r1.78 --- changelog.xml 26 Jul 2004 15:39:13 - 1.77 +++ changelog.xml 26 Jul 2004 17:04:04 - 1.78 @@ -14,7 +14,7 @@ body -section name=Tomcat 5.0.28 (yoavs) +section name=Tomcat 5.5.0 (yoavs) subsection name=General changelog fix - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 5: Support for multiple Coyote JK-Pools
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: Rainer Jung wrote: Am I right, that by design TC 5 only fully supports one Coyote JK pool at the moment? I enabled JMX HTTP adaptor via mx.enabled=true. Obviously org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not only once, but for every Coyote JK pool configured in server.xml. For the second pool I get an exception when starting tomcat (see below). When trying to stop TC, the Coyote HTTP pool is shut down correctly, and one of the two JK pools doesn't listen any more, but the second JK pool still listens and TC does not shut down. Retrying shutdown does not help, the process is still alive. Any plans (or work already done) to refactor JkMain/JkMX for 5.next? Yes: use JDK 1.5 JMX instead of this code. Are we going to switch to JDK1.5 ??? I missed this one. Actually, I posted that we could consider switching to JDK 1.5, yes (I do really like that JDK). The idea is that I'm tweaking the API, so I would use the new stuff when rewriting code. I don't think it'll happen in the end, since not many people seem to be in favor of it. Here, I was mentioning that using JDK 1.5 would be a workaround (as the connector registration moves out of the JVM). Well, I like JDK1.5 as well - but I think we should follow the same path of keeping the base functionality available on lower VMs, and restrict 1.5 to individual components. Not sure what you mean with connector registration moves out of jvm tough, but it sounds interesting :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dynamic updates and Apache v2.0
First, by dynamic updates I mean changes to apache2 config that don't require a restart. For example, .htaccess files provide such a thing ( for a different area ). What updates ? There are several forms: 1. - add a new worker to a pool ( for example - expect big load, you buy more hardware, etc ). - gracefully remove a worker ( for upgrade for example ) - the implication is that sticky sessions will still go, no new sessions. - change parameters of a worker ( like balancing factors ). That may include advanced balancing. Note that for all this you don't actually need too much change on apache/mod_proxy - as long as you treat the pool as one entity, and maybe use a separate config file for the list of workers ( so you don't have to regenerate httpd.conf - which is quite difficult ). There are many ways to implement the communication between httpd processes and between apache and tomcat. 2. - add more webapps and virtual servers - for example in the case of an ISP. - reload webapps - that means some mappings and auth changes, in the case of tight integration you may want to have apache handle auth and mapping Costin Graham Leggett wrote: Hi all, I am starting a new thread for this, as it seems to be an important killer-app feature for any httpd v2.0 integration. People have said the config should be dynamically configurable - which part of the config should be dynamically configurable? In other words, would any of these senarios make sense: - A potential pool of servers (IP address/port combinations) is defined, and httpd gracefully handles the case where a server is missing. Adding a new server is as simple as starting it up on one of the predefined ip/ports combinations. An admin might configure an entire subnet as tomcat servers, and then add and remove backend servers at will. Easy to do, but a bit limiting. - httpd is informed via a special URL of updates to the servers on the backend, a bit like the management app in tomcat. This functionality might grow to being available to the whole httpd config. Being a URL, it would be pretected by standard mechanisms like SSL and basic authentication. Powerful, but a big change that will likely only appear in httpd v2.1 or v2.2. - httpd polls the backend servers using the OPTIONS method (as was recommended recently). In the info returned, httpd learns of the intended weighting of the servers, whether a server needs to be removed gracefully from the pool, or whether other servers have been added to the pool and should be included in the config. Here httpd needs only to be told about just one backend server, which will seed httpd with info about all the other servers. Out of the above three the third option seems to make the most sense. It's not very obtrusive, it can be used with backends other than tomcat. Actually updating the server list and weightings can be done via the tomcat management app, which already exists now (as opposed to a theoritical management app for httpd). Thoughts? Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Mladen Turk wrote: Costin Manolache wrote: Mladen Turk wrote: Of course, no one is forced to participate in development, but everyone is welcome. The only question is do we have enough juice to make it official. AFICT, Remy, Henri and myself are in favor. But frankly I see no reason for someone to object, cause it's open source after all, and it doesn't break nothing that already exists. I'm not in favor, quite the contrary. And I thing there are reasons to object - doesn't break anthing that exists is not the only criteria used in apache. Is it the best solution ? can be used sometimes. I must disagree with you. There has been previous talks about 'wasting resources', that looks just like some corporate manager would talk. You can not stop people seeking other solutions, trying to build something better. It's the compete opposition of what IMO ASF stands for. At least in Apache httpd project - it seems they are not willing to accept solutions that just work, they also try to find the best solution and take the long-term into account. If I make a design flaw, and the entire project gets unusable, it will make it just something like mod_java, mod_warp, mod_jk and mod_jk2 are... Dead. Nobody will get hanged for that. It's not as simple. Users will have to invest time in learning and setting up this new tool, etc. I don't think the goal is to accumulate more mod_warp, mod_jk, mod_jk2 - but to learn from the past errors and do something better. In any case - even if I'm no longer a very active tomcat committer, I think I can still -1 something that doesn't have a clear set of requirements, doesn't have a clear design that is able to support those features, doesn't have a configuration that is easy ( and by that I mean familiar for admins ), etc. You can ignore my vote if you want, but I'm pretty sure I am right. What about free spirit, and creative mess, that produced something like Apache2 and Tomcat. Are we going to need to have a full set of requirements and marketing analysis for each patch we make? Well, both Apache2 and Tomcat ( even tomcat3 ) had some design and requirements ( == goals ). And at least in apache2 I remember they did spent the time to discuss this and figure out the best design ( and quite a few creative solutions were not accepted ). Take a look at apache filters, or APR. This is not just a patch ( and even if it was - I think it's perfectly reasonable to think about the long-term goals on each patch - and not add features just because we can ). Usually spaghetti is the imediate result of accepting every feature. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Henri Gomez wrote: Costin Manolache wrote: Mladen Turk wrote: Of course, no one is forced to participate in development, but everyone is welcome. The only question is do we have enough juice to make it official. AFICT, Remy, Henri and myself are in favor. But frankly I see no reason for someone to object, cause it's open source after all, and it doesn't break nothing that already exists. I'm not in favor, quite the contrary. And I thing there are reasons to object - doesn't break anthing that exists is not the only criteria used in apache. Is it the best solution ? can be used sometimes. Well I've got more than one reason to object to current jk2 and jk. This is not about objecting to current jk and jk2. They are where they are because of some design and requirement errors. The whole point is to avoid this. It should be obvious that adding important features as an after-tough and starting with just code that doesn't break instead of a sound requirements and design will likely lead to the same spaghetti and mess in the long run. I said that some known Tomcat instances, Remy asked us to avoid the old jk/jk2 naming, are set in Apache 2 by default, but nothing prevent us to add new instance dynamically, via ajp_status or mod_status or whatever (may be even via AJP/1.4). Nothing prevented us to add any feature to mod_jk.x either. 3 years ago we didn't know all those requirements - few people were thinking at that time that tomcat will be used in allways on configurations. And if dynamic config is not on the list - then it won't solve the problem for people who really need apache+tomcat, i.e. many large sites with uptime requirements. Why confuse the people with yet another connector - and what hope can we have it will not have the same fate as mod_webapp ? I'm handling sites requiring this kind of requirement and it's high on my mod_ajp features wish list. When you operate sites which works 24/24 and 7/7 and need to add horse power, it's a nightmare to have to wait some period in the night to make the Apache server update and restart. Also admins may want to add some power for a short period of time, so adding and removing such instances should be easy and quick. Ok, so what is the plan to support this in mod_ajp ? Is this on the list of requirements - and for that matters, what is the list ? If it is, again, how do you plan to support it ? It's not a trivial issue, reconfiguration is very hard - and most likely to create a lot of spaghetti. It's not funny how we allways refuse to learn from our mistakes, and periodically repeat them Well I'd like to resume the mod_ajp goal : - an APR/Apache 2 specific module (no more mess with #ifdef for 30 differents OS, we're in 2004). - extract ajp stuff and put it in an ajp library, which could be used outside within the Apache 2.0 module, used by proxy_ajp and of course in others applications, ie ajp-bench. - Study what has been done in mod_proxy to follow the start of art in Apache 2.x dev and make sure we could works with others AP2 modules. - Add/Remove/Update of Tomcat instances, and allow to attach/map them to URI and LB instances. What about adding/updating of webapps ? Is this a feature that will never be added ( because if it will be and it is not part of the design - then we're back to spaghetti ) Costin will probably mention JMX/CMX support, but I think this is something so important that it should be in HTTPD-dev and not only in mod_ajp. JMX is just a mean to an end. The goal is dynamic configuration ( i.e. without restart ). Yes, it should be more available in httpd-dev ( they do have some with .htaccess, etc ), but we have few clear use cases they don't. Well - dynamic add/remove of webapps is quite trivial in apache, you can add cgis/php/etc without restarting the server even today. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress, more ideas and native connector benchmarks
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: Costin Manolache wrote: Both difference and similarity :-). Eclipse ( osgi actually ) has a similar flat loader implementation, but with finer control over what is exported/imported and pretty strong versioning. In addition osgi supports permissions on importing packages. The reloading of modules is a bit more complicated than in jboss ( where you just change the jar ). From tomcat point of view - the implementation should be very similar with jboss. What I like is the standardized and simpler behavior of class loaders, with ability to reload and upgrade any module ( like jboss ). This classloader looks like it does stuff :) I recommend plugging it in as usual, with the Loader interface. Is that ok ? It should be, plugging tomcat into anything is usually simple. The current tomcat loading mechanism - with 2 hierarchies of class loaders and the delegation hacks, plus the very rigid isolation between webapps - is far from perfect. Again, it's a matter of interpreting the servlet spec - they do have some clear requirements on class loading, but I can't find any place where they forbid using other standards. I know adding an optional OSGI manifest could be controversial - but the benefits will be quite big. It would mean you can finally have arbitrary multiple versions of the same package, or have fine control ( using java permissions ) over what packages can be imported in a webapp or plugin. And it would mean an unified model for both webapps and plugins ( connectors, etc ). The other very interesting aspects of eclipse are the extension point and the ( extreme ) laziness in loading plugins. I imagined something a bit like that (with plenty of CLs each containing a particular version of a JAR), but: - I got a big headache, and I don't think I'm capable of not screwing it up :D (so I decided to keep the current CL, which kinda works) - I would take me a lot of time, and it wouldn't be useful to my employer, so they wouldn't be too happy in the end I'd be really curious to see how you implemented all that stuff :) Well, I don't have a lot of free time, so reimplementing all this stuff is not a choice, and I don't want the headaches :-). Eclipse, oscar, knopflerfish ( last 2 with BSD licence ) already implement the class loaders - and there osgi standard is available in many other implementations ( sun embedded web server, etc ). Jboss and eclipse use the same class loading mechanism - and the same model for plugins. It would be really nice if jboss will make one extra step and add the missing features from osgi ( fine control of export/import and use the version information to match the loader ), and even better if they would do this using the standard osgi manifest. I think the granularity of jboss integration is a bit high - what I'm trying is to have each plugin( connector, auth, etc) as well as each webapp in a separate bundle - so you can add/remove/upgrade plugins just like eclipse does, without restart and with on-demand loading. ( I haven't checked the last jboss tough - maybe it alreay does that :-) Anyway - it's work in progress, I don't know all details - the basic stuff obviouslty works ( since it works in jobss as well ), I can load/unload tomcat and individual connectors from eclipse console without problems. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30325] New: - $CATALINA_HOME set unconditionally in bin/catalina.sh
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30325. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30325 $CATALINA_HOME set unconditionally in bin/catalina.sh Summary: $CATALINA_HOME set unconditionally in bin/catalina.sh Product: Tomcat 5 Version: 5.0.27 Platform: All OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] ...whereas in bin/catalina.bat it is only set if not defined, as documented. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Henri Gomez wrote: Costin Manolache wrote: Mladen Turk wrote: Of course, no one is forced to participate in development, but everyone is welcome. The only question is do we have enough juice to make it official. AFICT, Remy, Henri and myself are in favor. But frankly I see no reason for someone to object, cause it's open source after all, and it doesn't break nothing that already exists. I'm not in favor, quite the contrary. And I thing there are reasons to object - doesn't break anthing that exists is not the only criteria used in apache. Is it the best solution ? can be used sometimes. Well I've got more than one reason to object to current jk2 and jk. This is not about objecting to current jk and jk2. They are where they are because of some design and requirement errors. The whole point is to avoid this. It should be obvious that adding important features as an after-tough and starting with just code that doesn't break instead of a sound requirements and design will likely lead to the same spaghetti and mess in the long run. I said that some known Tomcat instances, Remy asked us to avoid the old jk/jk2 naming, are set in Apache 2 by default, but nothing prevent us to add new instance dynamically, via ajp_status or mod_status or whatever (may be even via AJP/1.4). Nothing prevented us to add any feature to mod_jk.x either. 3 years ago we didn't know all those requirements - few people were thinking at that time that tomcat will be used in allways on configurations. Now we do. And if dynamic config is not on the list - then it won't solve the problem for people who really need apache+tomcat, i.e. many large sites with uptime requirements. Why confuse the people with yet another connector - and what hope can we have it will not have the same fate as mod_webapp ? I'm handling sites requiring this kind of requirement and it's high on my mod_ajp features wish list. When you operate sites which works 24/24 and 7/7 and need to add horse power, it's a nightmare to have to wait some period in the night to make the Apache server update and restart. Also admins may want to add some power for a short period of time, so adding and removing such instances should be easy and quick. Ok, so what is the plan to support this in mod_ajp ? Is this on the list of requirements - and for that matters, what is the list ? If it is, again, how do you plan to support it ? It's not a trivial issue, reconfiguration is very hard - and most likely to create a lot of spaghetti. Well I'd like to resume the mod_ajp goal : - an APR/Apache 2 specific module (no more mess with #ifdef for 30 differents OS, we're in 2004). - extract ajp stuff and put it in an ajp library, which could be used outside within the Apache 2.0 module, used by proxy_ajp and of course in others applications, ie ajp-bench. - Study what has been done in mod_proxy to follow the start of art in Apache 2.x dev and make sure we could works with others AP2 modules. - Add/Remove/Update of Tomcat instances, and allow to attach/map them to URI and LB instances. What about adding/updating of webapps ? Is this a feature that will never be added ( because if it will be and it is not part of the design - then we're back to spaghetti ) Costin will probably mention JMX/CMX support, but I think this is something so important that it should be in HTTPD-dev and not only in mod_ajp. JMX is just a mean to an end. The goal is dynamic configuration ( i.e. without restart ). Yes, it should be more available in httpd-dev ( they do have some with .htaccess, etc ), but we have few clear use cases they don't. Well - dynamic add/remove of webapps is quite trivial in apache, you can add cgis/php/etc without restarting the server even today. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress, more ideas and native connector benchmarks
I committed a few things: - The new deployer is getting there. Missing is the support for the manager webapp, but this won't be too hard to write. - I redid partially the naming. Now the NamingResource object is the main object, and Context is not polluted. My list is: - Update manager webapp, and add support for it in HostConfig (incl JMX registration). - Remove Deployer and DefaultContext. The new stuff looks like a better replacement. - HTML host manager servlet (allows easily creating host and preconfiguring them - ex: with the manager webapp installed, and a default context file). - Try to optimize startup time, if possible. - As mentioned in my commit message, I don't think the dynamic updates to the naming environment are useful. The code which does that is relatively complex (although it's not as bad as before with the ResourceParams). My opinion is that if something is not useful, then it should go ;) Any comments on that fancy feature ? - I'll have a lot of work updating the docs now :-P (I guess the fun is nearly over :( ) - The admin webapp will need some tweaks after removing the DefaultContext. The commit message on my last commit didn't seem to go through, so here it is: - As I discussed earlier, switch to a nicer looking syntax for naming stuff, using setAllProperties. This simplifies the code a lot. - Example: Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / - Remove the horrible ResourceParams, and add new objects for transaction and resourceRefs. - At the same time, big cleanup of the code. - Removing the (completely useless) facading the Context was doing for the NamingResources object. This is something I couldn't do in 4.1.x because we didn't want to change the API. The last thing I didn't remove is some messaging stuff. What's that ? - Some tweaking will likely be needed (for example, the save-to-XML code needs to save all the extra properties). However, a lot of stuff won't need to be adjusted, as it was using NamingResources (I don't think the naming support in the admin webapp is going to need anything). - I'm wondering how useful it is to be able to dynamically update the associated naming context. I think we should remove that, and just reload the webapp (since I think most webapps won't be able to handle dynamic changes in the ENC). I'll post about that in my next progress email. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
jean-frederic clere wrote: We have noted that mod_proxy + mod_proxy_http are slow compared with mod_jk. I think that the next step should be to try to find why instead writting a new modules. May be a quick hacked mod_proxy_ajp to replace mod_proxy_http is the first step. Note that I am a bit reluctant to start a new module because I already had lost a lot of time in mod_webapp ;-( A lot of people lost time on various connectors, so you're not alone ;) (the list includes me with my old HTTP connector in Tomcat 4.0) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mod_ajp initial
Costin Manolache wrote: Mladen Turk wrote: If I make a design flaw, and the entire project gets unusable, it will make it just something like mod_java, mod_warp, mod_jk and mod_jk2 are... Dead. Nobody will get hanged for that. I don't think the goal is to accumulate more mod_warp, mod_jk, mod_jk2 - but to learn from the past errors and do something better. OK then, do you have some other proposition, or just saying what we all said discussing this subject. AFICR you said that you will have something to share, and I'd love to see some other, perhaps better ideas. Well, both Apache2 and Tomcat ( even tomcat3 ) had some design and requirements ( == goals ). And at least in apache2 I remember they did spent the time to discuss this and figure out the best design ( and quite a few creative solutions were not accepted ). Take a look at apache filters, or APR. We are discussing too, right? And if you follow the discussion, you will find enough 'design leads'. There is nothing in the source tree jet, and the thread is named 'initial'. After all, I wrote that initial code in a single afternoon, so it's not such a big deal. MT. smime.p7s Description: S/MIME cryptographic signature
Re: [5.next] Progress, more ideas and native connector benchmarks
I'll volunteer for the admin webapp stuff. I enjoy deleting stuff from there ;-). - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, July 26, 2004 9:27 AM Subject: Re: [5.next] Progress, more ideas and native connector benchmarks I committed a few things: - The new deployer is getting there. Missing is the support for the manager webapp, but this won't be too hard to write. - I redid partially the naming. Now the NamingResource object is the main object, and Context is not polluted. My list is: - Update manager webapp, and add support for it in HostConfig (incl JMX registration). - Remove Deployer and DefaultContext. The new stuff looks like a better replacement. - HTML host manager servlet (allows easily creating host and preconfiguring them - ex: with the manager webapp installed, and a default context file). - Try to optimize startup time, if possible. - As mentioned in my commit message, I don't think the dynamic updates to the naming environment are useful. The code which does that is relatively complex (although it's not as bad as before with the ResourceParams). My opinion is that if something is not useful, then it should go ;) Any comments on that fancy feature ? - I'll have a lot of work updating the docs now :-P (I guess the fun is nearly over :( ) - The admin webapp will need some tweaks after removing the DefaultContext. The commit message on my last commit didn't seem to go through, so here it is: - As I discussed earlier, switch to a nicer looking syntax for naming stuff, using setAllProperties. This simplifies the code a lot. - Example: Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / - Remove the horrible ResourceParams, and add new objects for transaction and resourceRefs. - At the same time, big cleanup of the code. - Removing the (completely useless) facading the Context was doing for the NamingResources object. This is something I couldn't do in 4.1.x because we didn't want to change the API. The last thing I didn't remove is some messaging stuff. What's that ? - Some tweaking will likely be needed (for example, the save-to-XML code needs to save all the extra properties). However, a lot of stuff won't need to be adjusted, as it was using NamingResources (I don't think the naming support in the admin webapp is going to need anything). - I'm wondering how useful it is to be able to dynamically update the associated naming context. I think we should remove that, and just reload the webapp (since I think most webapps won't be able to handle dynamic changes in the ENC). I'll post about that in my next progress email. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for multiple Coyote JK-Pools
- Original Message - From: Rainer Jung [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 26, 2004 3:48 AM Subject: TC 5: Support for multiple Coyote JK-Pools Am I right, that by design TC 5 only fully supports one Coyote JK pool at the moment? Yes. If at some point we decide to deprecate support for JK2, then we could consider supporting multiple JK Connectors. If you *really* need to have multiple Connectors (and I can't see a usage case), try playing with the jkHome attribute. I enabled JMX HTTP adaptor via mx.enabled=true. Obviously org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not only once, but for every Coyote JK pool configured in server.xml. For the second pool I get an exception when starting tomcat (see below). When trying to stop TC, the Coyote HTTP pool is shut down correctly, and one of the two JK pools doesn't listen any more, but the second JK pool still listens and TC does not shut down. Retrying shutdown does not help, the process is still alive. Any plans (or work already done) to refactor JkMain/JkMX for 5.next? Well, I believe the consensus is to deprecate JkMX in 5.next. It's pretty outdated now, and it certainly doesn't belong in the Connector code. Rainer Jung Exception during start: 2004-07-26 12:37:58,929 (main) org.apache.jk.common.JkMX/ERROR: Can't load the MX4J http adapter javax.management.InstanceAlreadyExistsException: Http:name=HttpAdaptor at mx4j.server.MBeanServerImpl.register(MBeanServerImpl.java:1123) at mx4j.server.MBeanServerImpl.registerImpl(MBeanServerImpl.java:1054) at mx4j.server.MBeanServerImpl.registerMBeanImpl(MBeanServerImpl.java:1002) at mx4j.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:978) at org.apache.jk.common.JkMX.registerObject(JkMX.java:314) at org.apache.jk.common.JkMX.loadAdapter(JkMX.java:157) at org.apache.jk.common.JkMX.init(JkMX.java:268) at org.apache.jk.server.JkMain.start(JkMain.java:339) at org.apache.jk.server.JkCoyoteHandler.start(JkCoyoteHandler.java:193) at org.apache.coyote.tomcat5.CoyoteConnector.start(CoyoteConnector.java:1527) at org.apache.catalina.core.StandardService.start(StandardService.java:489) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2313) at org.apache.catalina.startup.Catalina.start(Catalina.java:556) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:284) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:422) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30325] - $CATALINA_HOME set unconditionally in bin/catalina.sh
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30325. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30325 $CATALINA_HOME set unconditionally in bin/catalina.sh --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 17:24 --- Created an attachment (id=12226) Patch not to set $CATALINA_HOME if already defined (applies to bin/catalina.sh). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30325] - [PATCH] $CATALINA_HOME set unconditionally in bin/catalina.sh
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30325. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30325 [PATCH] $CATALINA_HOME set unconditionally in bin/catalina.sh [EMAIL PROTECTED] changed: What|Removed |Added Summary|$CATALINA_HOME set |[PATCH] $CATALINA_HOME set |unconditionally in |unconditionally in |bin/catalina.sh |bin/catalina.sh --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 17:27 --- Provided patch to fix the problem. Done on Tomcat 5.0.27 but works on 5.0.25 as well. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Mladen Turk wrote: Costin Manolache wrote: Mladen Turk wrote: If I make a design flaw, and the entire project gets unusable, it will make it just something like mod_java, mod_warp, mod_jk and mod_jk2 are... Dead. Nobody will get hanged for that. I don't think the goal is to accumulate more mod_warp, mod_jk, mod_jk2 - but to learn from the past errors and do something better. OK then, do you have some other proposition, or just saying what we all said discussing this subject. AFICR you said that you will have something to share, and I'd love to see some other, perhaps better ideas. No, I'm trying stuff on java side. And just like with code - I don't think we are missing propositions or ideas. What is missing is an agreement over what features we are going to support ( and more exactly - not support ), as well as a clear plan on how to support them without spaghetti. I think we do have agreement on droping IIS/iPlanet. We had agreement on droping pluggable protocol - but that's now back with the discussion on mod_proxy ( which also involves pluggable protocol ). Well, both Apache2 and Tomcat ( even tomcat3 ) had some design and requirements ( == goals ). And at least in apache2 I remember they did spent the time to discuss this and figure out the best design ( and quite a few creative solutions were not accepted ). Take a look at apache filters, or APR. We are discussing too, right? And if you follow the discussion, you will find enough 'design leads'. There is nothing in the source tree jet, and the thread is named 'initial'. After all, I wrote that initial code in a single afternoon, so it's not such a big deal. Yes, we do have plenty of connectors, and most were written very fast - mod_jserv, mod_jk, mod_jk2, mod_webapp, mod_proxy. Having a 6th codebase - especially in the context of the growing agreement over mod_proxy as a long-term solution - is not what is missing. My concern is that we are just repeating the history of the first 4 connectors - by writting some initial code that solves the easy problem ( sending requests to tomcat ), and hoping the rest can be added without getting back to spaghetti. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 5: Support for multiple Coyote JK-Pools
Costin Manolache wrote: Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: Rainer Jung wrote: Am I right, that by design TC 5 only fully supports one Coyote JK pool at the moment? I enabled JMX HTTP adaptor via mx.enabled=true. Obviously org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not only once, but for every Coyote JK pool configured in server.xml. For the second pool I get an exception when starting tomcat (see below). When trying to stop TC, the Coyote HTTP pool is shut down correctly, and one of the two JK pools doesn't listen any more, but the second JK pool still listens and TC does not shut down. Retrying shutdown does not help, the process is still alive. Any plans (or work already done) to refactor JkMain/JkMX for 5.next? Yes: use JDK 1.5 JMX instead of this code. Are we going to switch to JDK1.5 ??? I missed this one. Actually, I posted that we could consider switching to JDK 1.5, yes (I do really like that JDK). The idea is that I'm tweaking the API, so I would use the new stuff when rewriting code. I don't think it'll happen in the end, since not many people seem to be in favor of it. Here, I was mentioning that using JDK 1.5 would be a workaround (as the connector registration moves out of the JVM). Well, I like JDK1.5 as well - but I think we should follow the same path of keeping the base functionality available on lower VMs, and restrict 1.5 to individual components. Not sure what you mean with connector registration moves out of jvm tough, but it sounds interesting :-) Bad sentence, it should be moves to the JVM. I don't know if you tried it, but there's a management.properties file that has all the options you could dream of to configure JMX remote :) Then you get fancy graphs without having to configure anything in Tomcat (http://mc4j.sourceforge.net/15Features_large.gif and the more classic http://mc4j.sourceforge.net/ss5_large.gif). So it's less code in Tomcat for something a lot more powerful = I like it (even if I have to remove all the enum variables from my code). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
[EMAIL PROTECTED] wrote: billbarker2004/07/26 10:04:04 Modified:webapps/docs changelog.xml Log: Fix version #. What ever the next version is that is released from here, it is not going to be called 5.0.x. I did refer to that with the 5.5 revision number, because the API isn't compatible, and because I wanted to tweak it for JDK 1.5 (or JDK 5.0, whatever). So it's a lot of 5s. Revision ChangesPath 1.78 +1 -1 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.77 retrieving revision 1.78 diff -u -r1.77 -r1.78 --- changelog.xml 26 Jul 2004 15:39:13 - 1.77 +++ changelog.xml 26 Jul 2004 17:04:04 - 1.78 @@ -14,7 +14,7 @@ body -section name=Tomcat 5.0.28 (yoavs) +section name=Tomcat 5.5.0 (yoavs) subsection name=General changelog fix Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 5: Support for multiple Coyote JK-Pools
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: Rainer Jung wrote: Am I right, that by design TC 5 only fully supports one Coyote JK pool at the moment? I enabled JMX HTTP adaptor via mx.enabled=true. Obviously org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not only once, but for every Coyote JK pool configured in server.xml. For the second pool I get an exception when starting tomcat (see below). When trying to stop TC, the Coyote HTTP pool is shut down correctly, and one of the two JK pools doesn't listen any more, but the second JK pool still listens and TC does not shut down. Retrying shutdown does not help, the process is still alive. Any plans (or work already done) to refactor JkMain/JkMX for 5.next? Yes: use JDK 1.5 JMX instead of this code. Are we going to switch to JDK1.5 ??? I missed this one. Actually, I posted that we could consider switching to JDK 1.5, yes (I do really like that JDK). The idea is that I'm tweaking the API, so I would use the new stuff when rewriting code. I don't think it'll happen in the end, since not many people seem to be in favor of it. Here, I was mentioning that using JDK 1.5 would be a workaround (as the connector registration moves out of the JVM). Well, I like JDK1.5 as well - but I think we should follow the same path of keeping the base functionality available on lower VMs, and restrict 1.5 to individual components. Not sure what you mean with connector registration moves out of jvm tough, but it sounds interesting :-) Bad sentence, it should be moves to the JVM. I don't know if you tried it, but there's a management.properties file that has all the options you could dream of to configure JMX remote :) Then you get fancy graphs without having to configure anything in Tomcat (http://mc4j.sourceforge.net/15Features_large.gif and the more classic http://mc4j.sourceforge.net/ss5_large.gif). So it's less code in Tomcat for something a lot more powerful = I like it (even if I have to remove all the enum variables from my code). Yes, I know jdk1.5 has this - however I tought we want to support this for lower VMs as well, it's important enough. And the typical solution is to have a module that does this - it is in j-t-c for the simple reason that coyote is used with all tomcat versions ( 3.3, 4.x, 5.x ) - so it is easier to place it there. IMO we should stop making a strong distinction between the different plugins - connector, authenticator, logger, mapper, etc. They are all plugins, and it makes perfect sense to have a plugin that adds a jmx feature that is present in jdk1.5 and makes it available in jdk1.3 - that means easier transition to 1.5, consistent behavior, etc. BTW - I preffer the http/servlet-based jmx console, as in mx4j or jboss. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/conf server-minimal.xml
remm2004/07/26 12:35:00 Modified:catalina/src/conf server-minimal.xml Log: - Update server minimal as well. Revision ChangesPath 1.5 +3 -12 jakarta-tomcat-catalina/catalina/src/conf/server-minimal.xml Index: server-minimal.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/server-minimal.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- server-minimal.xml23 Jun 2004 13:51:38 - 1.4 +++ server-minimal.xml26 Jul 2004 19:34:59 - 1.5 @@ -3,18 +3,9 @@ !-- Used by Manager webapp -- Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase - description=User database that can be updated and saved -/Resource -ResourceParams name=UserDatabase - parameter -namefactory/name -valueorg.apache.catalina.users.MemoryUserDatabaseFactory/value - /parameter - parameter -namepathname/name -valueconf/tomcat-users.xml/value - /parameter -/ResourceParams + description=User database that can be updated and saved + factory=org.apache.catalina.users.MemoryUserDatabaseFactory + pathname=conf/tomcat-users.xml / /GlobalNamingResources Service name=Catalina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
PATCH: mod_jk get_cookie jvmroute fix
Attached is a patch that fixes the get_cookie in jk_lb_worker.c taken from the CVS today. The current implementation will fail if there are two JSESSIONID cookies at different domain levels. My patch below checks a JSESSIONID value for a known jvmroute before it returns a session cookie. The logic isn't perfect but it better than the current implementation IMO. It could be made more correct if it verified the found jvmroute was at the end of the cookie's value instead of simply doing a strstr() for it. One could also argue that this changes the behavior enough that the function should be renamed as it's no longer a generic get_cookie function. That said, the current patch, altered for mod_jk 1.2.5, is currently in production for webmail.ufl.edu where it's getting 15+ requests a second. Sandy McArthur jk_lb_worker.c-check-jvmroute.patch Description: Binary data smime.p7s Description: S/MIME cryptographic signature
Re: Mod_ajp initial
Remy Maucherat wrote: jean-frederic clere wrote: We have noted that mod_proxy + mod_proxy_http are slow compared with mod_jk. I think that the next step should be to try to find why instead writting a new modules. May be a quick hacked mod_proxy_ajp to replace mod_proxy_http is the first step. Note that I am a bit reluctant to start a new module because I already had lost a lot of time in mod_webapp ;-( A lot of people lost time on various connectors, so you're not alone ;) (the list includes me with my old HTTP connector in Tomcat 4.0) Rémy Mod_jk, mod_jk2, http connector in 3.3, few ajp connectors and jserv on the java side, etc - it seems I lost quite a bit of time on connectors :-) I'm more worried about lost of important features and things we learned than lost of code or even time. Most of the time was well spent - to learn stuff and solve problems, maybe not with the best solution but the best we could at that point. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jeg er på ferie
I will be out of the office starting 23.07.2004 and will not return until 16.08.2004. Jeg sjekker mail innimellom. Er det ting rundt drift send mail til [EMAIL PROTECTED] Ha en fortsatt fin dag. Mvh Richard D. Nilsen Orkla Media SSIT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dynamic updates and Apache v2.0
Costin Manolache wrote: 1. - add a new worker to a pool ( for example - expect big load, you buy more hardware, etc ). - gracefully remove a worker ( for upgrade for example ) - the implication is that sticky sessions will still go, no new sessions. - change parameters of a worker ( like balancing factors ). That may include advanced balancing. Note that for all this you don't actually need too much change on apache/mod_proxy - as long as you treat the pool as one entity, and maybe use a separate config file for the list of workers ( so you don't have to regenerate httpd.conf - which is quite difficult ). There are many ways to implement the communication between httpd processes and between apache and tomcat. Don't forget that in many cases Apache will be running on a machine entirely outside of your direct control - a good example would be a network appliance. There are many options for httpd to connect to the backend, and for the backend to connect to httpd, but there are limitations imposed by the environment where httpd will be running. Reading a file on disk is one example (you mentioned .htaccess files) - changing the file on disk does not mean httpd is necessarily going to pick up the changes straight away, and this assumes the admin has disk access at all. Whatever solution we start with needs to keep these limitations in mind. 2. - add more webapps and virtual servers - for example in the case of an ISP. - reload webapps - that means some mappings and auth changes, in the case of tight integration you may want to have apache handle auth and mapping Adding virtual servers requires an httpd config reload, this moves into the territory of having an httpd management app along the lines of the tomcat management app. Not a bad idea in itself, but a big project for httpd. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
RE: Mod_ajp initial
Costin Manolache wrote: AFICR you said that you will have something to share, and I'd love to see some other, perhaps better ideas. No, I'm trying stuff on java side. OK. And just like with code - I don't think we are missing propositions or ideas. What is missing is an agreement over what features we are going to support ( and more exactly - not support ), as well as a clear plan on how to support them without spaghetti. I think we do have agreement on droping IIS/iPlanet. We had agreement on droping pluggable protocol Apache2, ajp13, TCP/IP With possible dynamic config in stage 2 and ajp14 protocol extension using crypto and compression. That's it. We said that couple of times. - but that's now back with the discussion on mod_proxy ( which also involves pluggable protocol ). True, the work on that has been initiated, but it has a fundamental difference being included in core httpd distribution. Only that fact is a sufficient reason to forget that 'no plugable protocol' agreement, thought, and of course the fact that the proxy is deeply integrated into the core of httpd, as well as our protocol will consequently. Yes, we do have plenty of connectors, and most were written very fast - mod_jserv, mod_jk, mod_jk2, mod_webapp, mod_proxy. Having a 6th codebase - especially in the context of the growing agreement over mod_proxy as a long-term solution - is not what is missing. Well, the way I see (think that Henri has the similar ideas) is to have the ajp protocol lib, usable to communicate to TC from any container, not only http server, and mod_ajp as a layer on top of it _only_ for Apache 2.0 branch _and_only_ if the proxy_ajp doesn't get back propagated from 2.1 branch. So from the start we know what the final goal is, and what the life cycle of it would be. The code itself (at least the ajp protocol library) will not be a waste, cause we'll use it for both proxy_ajp and any later bizarre usage. To effectively test the new ajp code we need some framework, simple enough and Apache2 centric. We could use the current mod_proxy for that, but it's current design need some changes to be able to support that, and BTW I'm working on that together with Graham, but even he can not say for sure it's going to be in 2.0 branch. There is also a question of development infrastructure, cause we cannot use the httpd-cvs for that, so we'll need to make some compromises, writing few lines of code twice, and hope that somone will apply the patch :). My concern is that we are just repeating the history of the first 4 connectors - by writting some initial code that solves the easy problem ( sending requests to tomcat ), and hoping the rest can be added without getting back to spaghetti. Well, the only thing you can not beat is the time. It (the time) has a strange side effect to make the things older. I clearly remember a day when I stood speechless in front of a VAX mainframe with 1MB of RAM, wondering who will ever need that and for what. MT. smime.p7s Description: S/MIME cryptographic signature
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
kinman 2004/07/26 13:50:36
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
- Fix 30291: Smap for a tag should not include its body.
- Fix 30289: Incorrect Smap for multiple line java expression.
Revision ChangesPath
1.236 +8 -5
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.235
retrieving revision 1.236
diff -u -r1.235 -r1.236
--- Generator.java23 Jul 2004 22:45:38 - 1.235
+++ Generator.java26 Jul 2004 20:50:35 - 1.236
@@ -830,7 +830,9 @@
public void visit(Node.Expression n) throws JasperException {
n.setBeginJavaLine(out.getJavaLine());
-out.printil(out.print( + n.getText() + ););
+out.printin(out.print();
+out.printMultiLn(n.getText());
+out.println(););
n.setEndJavaLine(out.getJavaLine());
}
@@ -2125,9 +2127,9 @@
Class tagHandlerClass = handlerInfo.getTagHandlerClass();
-n.setBeginJavaLine(out.getJavaLine());
out.printin(// );
out.println(n.getQName());
+n.setBeginJavaLine(out.getJavaLine());
// Declare AT_BEGIN scripting variables
declareScriptingVars(n, VariableInfo.AT_BEGIN);
@@ -2221,7 +2223,10 @@
out.pushIndent();
}
}
-};
+// Map the Java lines that handles start of custom tags to the
+// JSP line for this tag
+n.setEndJavaLine(out.getJavaLine());
+}
private void generateCustomEnd(
Node.CustomTag n,
@@ -2327,8 +2332,6 @@
syncScriptingVars(n, VariableInfo.AT_END);
restoreScriptingVars(n, VariableInfo.AT_BEGIN);
-
-n.setEndJavaLine(out.getJavaLine());
}
private void generateCustomDoTag(
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30289] - Wrong SMAP mappings with body dependent tags
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30289. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30289 Wrong SMAP mappings with body dependent tags [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 20:53 --- Fixed in CVS. Thanks for reporting. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30291] - Wrong smap in expressions and scriptlets
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30291. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30291 Wrong smap in expressions and scriptlets [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 20:54 --- Fixed in CVS. Thnaks for reporting. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/bin setclasspath.sh
markt 2004/07/26 14:29:42 Modified:catalina/src/bin setclasspath.sh Log: Fix bug 12056. Test for execute rather than read permissions since execute is what we need. Add missing JDK not JRE warning. Revision ChangesPath 1.13 +5 -4 jakarta-tomcat-4.0/catalina/src/bin/setclasspath.sh Index: setclasspath.sh === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/bin/setclasspath.sh,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- setclasspath.sh 12 Feb 2004 21:38:12 - 1.12 +++ setclasspath.sh 26 Jul 2004 21:29:42 - 1.13 @@ -11,13 +11,14 @@ exit 1 fi if $os400; then - if [ ! -r $JAVA_HOME/bin/java -o ! -r $JAVA_HOME/bin/javac ]; then + if [ ! -x $JAVA_HOME/bin/java -o ! -x $JAVA_HOME/bin/javac ]; then echo The JAVA_HOME environment variable is not defined correctly echo This environment variable is needed to run this program +echo NB: JAVA_HOME should point to a JDK not a JRE exit 1 fi else - if [ ! -r $JAVA_HOME/bin/java -o ! -r $JAVA_HOME/bin/jdb -o ! -r $JAVA_HOME/bin/javac ]; then + if [ ! -x $JAVA_HOME/bin/java -o ! -x $JAVA_HOME/bin/jdb -o ! -x $JAVA_HOME/bin/javac ]; then echo The JAVA_HOME environment variable is not defined correctly echo This environment variable is needed to run this program echo NB: JAVA_HOME should point to a JDK not a JRE @@ -29,7 +30,7 @@ echo This environment variable is needed to run this program exit 1 fi -if [ ! -r $BASEDIR/bin/setclasspath.sh ]; then +if [ ! -x $BASEDIR/bin/setclasspath.sh ]; then echo The BASEDIR environment variable is not defined correctly echo This environment variable is needed to run this program exit 1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30331] New: - META-INF/context.xml creates conf/.../foo.xml as a directory
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30331. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30331 META-INF/context.xml creates conf/.../foo.xml as a directory Summary: META-INF/context.xml creates conf/.../foo.xml as a directory Product: Tomcat 5 Version: 5.0.27 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have a WAR named survey.war with a META-INF/context.xml file declaring an alternate security realm. When I drop that WAR in tomcat/webapps, it creates conf/Catalina/localhost/survey.xml/ as a directory. The directory contains nothing. Then when redeploying, it complains that it's a directory not a file and gives a stack trace. Presumably, it should have just copied my context.xml to a file at that location -- I'm not sure why it creates it as a directory. EVERE: Error deploying configuration descriptor survey.xml java.io.IOException: java.io.FileNotFoundException: /server/tomcat-5.0.27/conf/Catalina/localhost/survey.xml (Is a directory) at org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:494) at org.apache.catalina.core.StandardHost.install(StandardHost.java:863) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:482) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:427) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:968) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:349) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1091) at org.apache.catalina.core.StandardHost.start(StandardHost.java:789) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1083) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:478) at org.apache.catalina.core.StandardService.start(StandardService.java:480) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2313) at org.apache.catalina.startup.Catalina.start(Catalina.java:556) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30332] New: - Field charsetSet reset problem in class org.apache.coyote.Response
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30332. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30332 Field charsetSet reset problem in class org.apache.coyote.Response Summary: Field charsetSet reset problem in class org.apache.coyote.Response Product: Tomcat 4 Version: 4.1.30 Platform: All OS/Version: All Status: NEW Severity: Critical Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We are still having problems with response content-type to have ;charset=UTF-8 automatically attached even though we explicitly called HttpServletResponse.setContentType(application/pdf) and never called setCharacterEncoding() in the same request. As a matter of fact, after putting some debugging code in org.apache.coyote.Response.setCharacterEncoding(), I found out it was never called in the request that we use to send the PDF file. The debugging also showed that the member variable charsetSet was true before setContentType() was called. Therefore, I suspect the recycle()/reset() method in this class wasn't called when it needs to be called. On the other hand, does it make sense to add charsetSet = false; at the beginning of the setContentType() method? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/bin setclasspath.sh
markt 2004/07/26 15:01:19 Modified:catalina/src/bin setclasspath.sh Log: Fix bug 12056. Test for execute rather than read permissions since execute is what we need. Add missing JDK not JRE warning. - Ported from TC4 Revision ChangesPath 1.8 +5 -4 jakarta-tomcat-catalina/catalina/src/bin/setclasspath.sh Index: setclasspath.sh === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/setclasspath.sh,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- setclasspath.sh 12 Feb 2004 21:38:56 - 1.7 +++ setclasspath.sh 26 Jul 2004 22:01:19 - 1.8 @@ -11,13 +11,14 @@ exit 1 fi if $os400; then - if [ ! -r $JAVA_HOME/bin/java -o ! -r $JAVA_HOME/bin/javac ]; then + if [ ! -x $JAVA_HOME/bin/java -o ! -x $JAVA_HOME/bin/javac ]; then echo The JAVA_HOME environment variable is not defined correctly echo This environment variable is needed to run this program +echo NB: JAVA_HOME should point to a JDK not a JRE exit 1 fi else - if [ ! -r $JAVA_HOME/bin/java -o ! -r $JAVA_HOME/bin/jdb -o ! -r $JAVA_HOME/bin/javac ]; then + if [ ! -x $JAVA_HOME/bin/java -o ! -x $JAVA_HOME/bin/jdb -o ! -x $JAVA_HOME/bin/javac ]; then echo The JAVA_HOME environment variable is not defined correctly echo This environment variable is needed to run this program echo NB: JAVA_HOME should point to a JDK not a JRE @@ -29,7 +30,7 @@ echo This environment variable is needed to run this program exit 1 fi -if [ ! -r $BASEDIR/bin/setclasspath.sh ]; then +if [ ! -x $BASEDIR/bin/setclasspath.sh ]; then echo The BASEDIR environment variable is not defined correctly echo This environment variable is needed to run this program exit 1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12056] - Startup scripts test for invalid permissions.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=12056. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=12056 Startup scripts test for invalid permissions. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 22:03 --- Your proposed patch has been applied to CVS for TC4 (and TC5). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30332] - Field charsetSet reset problem in class org.apache.coyote.Response
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30332. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30332 Field charsetSet reset problem in class org.apache.coyote.Response --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 23:01 --- A simple test case works for me and a check with telnet comfirms that the header is as expected. Can you provide a simple test case, perferably as a ready to deploy war, that exhibits this behaviour? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dynamic updates and Apache v2.0
why are we so focused on dynamic this dynamic that, there is nothing about mod_proxy that is dynamic, and instead of delaying the stability and release of a working mod_proxy with a load balancer, make it work, make it work well, then add fancy features. mod_jk2 became way to cluttered this exact way, and never got to the point of workability to the point where any user could configure it just my $0.02 Filip -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache Sent: Monday, July 26, 2004 11:30 AM To: [EMAIL PROTECTED] Subject: Re: Dynamic updates and Apache v2.0 First, by dynamic updates I mean changes to apache2 config that don't require a restart. For example, .htaccess files provide such a thing ( for a different area ). What updates ? There are several forms: 1. - add a new worker to a pool ( for example - expect big load, you buy more hardware, etc ). - gracefully remove a worker ( for upgrade for example ) - the implication is that sticky sessions will still go, no new sessions. - change parameters of a worker ( like balancing factors ). That may include advanced balancing. Note that for all this you don't actually need too much change on apache/mod_proxy - as long as you treat the pool as one entity, and maybe use a separate config file for the list of workers ( so you don't have to regenerate httpd.conf - which is quite difficult ). There are many ways to implement the communication between httpd processes and between apache and tomcat. 2. - add more webapps and virtual servers - for example in the case of an ISP. - reload webapps - that means some mappings and auth changes, in the case of tight integration you may want to have apache handle auth and mapping Costin Graham Leggett wrote: Hi all, I am starting a new thread for this, as it seems to be an important killer-app feature for any httpd v2.0 integration. People have said the config should be dynamically configurable - which part of the config should be dynamically configurable? In other words, would any of these senarios make sense: - A potential pool of servers (IP address/port combinations) is defined, and httpd gracefully handles the case where a server is missing. Adding a new server is as simple as starting it up on one of the predefined ip/ports combinations. An admin might configure an entire subnet as tomcat servers, and then add and remove backend servers at will. Easy to do, but a bit limiting. - httpd is informed via a special URL of updates to the servers on the backend, a bit like the management app in tomcat. This functionality might grow to being available to the whole httpd config. Being a URL, it would be pretected by standard mechanisms like SSL and basic authentication. Powerful, but a big change that will likely only appear in httpd v2.1 or v2.2. - httpd polls the backend servers using the OPTIONS method (as was recommended recently). In the info returned, httpd learns of the intended weighting of the servers, whether a server needs to be removed gracefully from the pool, or whether other servers have been added to the pool and should be included in the config. Here httpd needs only to be told about just one backend server, which will seed httpd with info about all the other servers. Out of the above three the third option seems to make the most sense. It's not very obtrusive, it can be used with backends other than tomcat. Actually updating the server list and weightings can be done via the tomcat management app, which already exists now (as opposed to a theoritical management app for httpd). Thoughts? Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.721 / Virus Database: 477 - Release Date: 7/16/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.721 / Virus Database: 477 - Release Date: 7/16/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30340] New: - substract() disfunctional in CharChunk and ByteChunk classes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=30340.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=30340
substract() disfunctional in CharChunk and ByteChunk classes
Summary: substract() disfunctional in CharChunk and ByteChunk
classes
Product: Tomcat 5
Version: 5.0.0
Platform: All
OS/Version: All
Status: NEW
Severity: Blocker
Priority: Other
Component: Connector:HTTP
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
If a jsp or a servlet uses char read() on its JspReader, the call is eventually
passed to CharChunk (or ByteChunk) substract() method. The method body needs
fixing to be functional, see:
public int substract()
throws IOException {
if ((end - start) == 0) {
if (in == null)
return -1;
int n = in.realReadChars(buff, 0, buff.length);
if (n 0)
return -1;
}
return (buff[start++]);
}
Should set end=start=0 after reading chars from in. The same for ByteChunk.
The next method, substract(CharChunk) does it... more or less.
Actually, I'd love to straighten up this code a little bit - but it would be
better to exchange opinions with the current author, Remy, regarding certain
methods and functionality, before doing anything.
Thanks,
Vlad Patryshev
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Mladen Turk wrote: Well, the way I see (think that Henri has the similar ideas) is to have the ajp protocol lib, usable to communicate to TC from any container, not only http server, and mod_ajp as a layer on top of it _only_ for Apache 2.0 branch _and_only_ if the proxy_ajp doesn't get back propagated from 2.1 branch. I agree with libajp.so. I don't agree we need to develop new connector for apache2.0. If we can't get it backported to 2.0 - then we can just provide a separate build ( mod_proxy21 ). So from the start we know what the final goal is, and what the life cycle of it would be. The code itself (at least the ajp protocol library) will not be a waste, cause we'll use it for both proxy_ajp and any later bizarre usage. To effectively test the new ajp code we need some framework, simple enough and Apache2 centric. We could use the current mod_proxy for that, but it's current design need some changes to be able to support that, and BTW I'm working on that together with Graham, but even he can not say for sure it's going to be in 2.0 branch. There is also a question of development infrastructure, cause we cannot use the httpd-cvs for that, so we'll need to make some compromises, writing few lines of code twice, and hope that somone will apply the patch :). We can very well put a copy of mod_proxy in our cvs while it is experimental - and give Graham access. The module can be tested/developed with both apache20 and 21. I don't think infrastructure is the biggest problem. We are all on apache. My concern is that we are just repeating the history of the first 4 connectors - by writting some initial code that solves the easy problem ( sending requests to tomcat ), and hoping the rest can be added without getting back to spaghetti. Well, the only thing you can not beat is the time. It (the time) has a strange side effect to make the things older. I clearly remember a day when I stood speechless in front of a VAX mainframe with 1MB of RAM, wondering who will ever need that and for what. My point was that repeating a mistake 4 times should be enough, we don't need a 5th repetition of the same history. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
