port number at runtime
It will be very usefull if the port number on which the SSL and Http non-ssl ports are running, is available runtime. (Ex:- 8080 and 8443). Is it possible? The int getPort() method of the CoyoteConnector class returns the port number but its not accessible at runtime. If there is a sendRedirect() method in some jsp, where one wants to redirect from http to say https, then the port number must be known in advance. So there is a need for such an API. -Saugata __ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.6 release ? - session tracking cookie
- Original Message - From: Sandy McArthur [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, July 19, 2004 9:15 PM Subject: Re: mod_jk 1.2.6 release ? - session tracking cookie On Jul 19, 2004, at 8:43 AM, Henri Gomez wrote: And since I couldn't delay the release to long, we need a quick reply, so thanks to take a look at it. We've setup a current CVS checkout of mod_jk at http://sp27en1.nerdc.ufl.edu/login.do which is load balancing to our webmail cluster. If you constantly reload the page you'll see it's setting a new JSESSIONID cookie on every request. Yup. Sending the cookie almost always fails to stick. Sending the jsessionid via URL-rewriting always sticks. So it does look like there is a bug with the lb cookie parsing. I can't see by looking at the code what it is however :(. I can probably find a machine that I can hook up with the HEAD code and lb to see what is going wrong, but I can't promise when. If you feel like putting more work into this, adding 'fprintf(stderr,...)' statements should go to the Apache error_log. For comparison https://webmail.ufl.edu/login.do is using mod_jk 1.2.5 load balancing to the same webmail cluster. Yup. This one will always stick with the cookie. Sandy McArthur 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: Some JK2 ideas v.3
Costin Manolache wrote I can understand the jk2 object oriented C is considered too complex. True. But I certainly can't agree on a design that is not modular and doesn't support this basic requirement. We already have mod_jserv and mod_webapp - and a long history of rewrite from scratch to make it simpler turning into far more complex code. But we don't wish to write something modular and unlimitedly extendable. Just the load-balancing-ajp13+ over tcp/ip connector, for Apache2. Having that in mind, we have APR, and 'almost' a finite set of requirements, without the need to 'think modular' or 'think cross-webserver'. Lot of the code would be reusable, but it would mean that making a mod_jni connector would mean to make a completely different project without some common directory holding shareable code. Also making any additional 'features' to the connector (like 'discovery' etc.) would have to be made as such, and enabled during compile time, so that the basic functionality remains as is. This means that we don't compile everything and then use the config to either enable or disable features, but rather make something like 'mpm concept' selectable at compile time. Seriously - if you take away the JMX and support for other servers - why not just use mod_jserv ? No one prevents you of making mod_jmx that will allow entire Apache2 to be maintainable trough JMX console, not only our module :). Regarding other servers you meant IIS (other are less then couple of percent) probably (apache13 users can use jk). I would like to make the 'real' IIS6 filter that will go in the NT kernel's http.sys, have dynamic thread pool and MMC snap-in, but that is something completely different. Few things like config tree, ajp protocol and transport can be reused cause now we have the APR that generalizes the OS layer. If you wish to write a good Apache2 module or IIS filter, they have to be different projects. Also being usable from admins point of view requires that the apache module is configurable trough httpd.conf, and IIS trough GUI. None of them uses JMX to configure the webserver thought. I have on my dash-board for a long time a project that will make a TC as a main web server, having Apache as a 'slave' for additional PHP and Perl support, but that also is something completely different and questionably usable. After all mod_jk and jk2 got complex because of additional requirements and features that we wanted to implement - if we drop them then we can just go back and use mod_jserv. Think that the main problem is that we don't understand the JK2 code any more, and that the modularity combined with crosswebserver became an obstacle rather then a feature. MT. smime.p7s Description: S/MIME cryptographic signature
DO NOT REPLY [Bug 28875] - Multi-byte characters in default error page aren't printed out correctly.
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=28875.
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=28875
Multi-byte characters in default error page aren't printed out correctly.
[EMAIL PROTECTED] changed:
What|Removed |Added
Platform|Macintosh |All
--- Additional Comments From [EMAIL PROTECTED] 2004-07-20 07:38 ---
This problem isn't yet solved in Tomcat 5.0.27 release.
It doesn't occur in 4.1.30 release, but always happens in 5.0.x release.
Any multi-byte character is not correctly printed into response reporter,
independently of the response locale setting.
Therefore, it is impossible to read every multi-byte error messages which is
displayed in default error page.
(And many Japanese users are in trouble very much.)
According to current ErrorReportValve source code, I have re-written my first
proposed patch (see the following diff code).
Please apply it.
Index: jakarta-tomcat-
catalina/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java
===
RCS file: /home/cvspublic/jakarta-tomcat-
catalina/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v
retrieving revision 1.21
diff -u -w -r1.21 ErrorReportValve.java
--- jakarta-tomcat-
catalina/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java
27 Jun 2004 23:56:23 - 1.21
+++ jakarta-tomcat-
catalina/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java
17 Jul 2004 20:59:20 -
@@ -284,19 +284,17 @@
try {
-Writer writer = response.getReporter();
-
-if (writer != null) {
-
-Locale locale = Locale.getDefault();
-
try {
response.setContentType(text/html);
- response.setLocale(locale);
+response.setCharacterEncoding(utf-8);
} catch (Throwable t) {
if (container.getLogger().isDebugEnabled())
container.getLogger().debug(status.setContentType,
t);
}
+
+Writer writer = response.getReporter();
+
+if (writer != null) {
// If writer is null, it's an indication that the response has
// been hard committed already, which should never happen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.3
Costin Manolache wrote: Henri Gomez wrote: You must keep in mind that tomcat5 is no longer server.xml centric ! It can use separate config files in different directories, if it is embedded it can use the embedor's config, etc. And httpd.conf is static - you can't modify it. We support using httpd.conf for performance-versus-flexibility or for native auth - if you want to use the apache mapper and auth instead of jk mapper and tomcat auth. Well httpd.conf is static but nothing prevent from doing : Location /examples AjpWorker myworker /Location = All /examples goes to myworker, which could be a simple tomcat or a cluster. but the idea behind is to make updates to this 'myworker' from the behind, JMX or AJP13++/AJP14 link. And what if /examples context is removed ? Well = 404 Since myworker didn't have examples webapp, the resource is missing and unless you're in a cluster configuration, you should return a 404 error. Or a new context is dynamically added ? If a new context is added, you couldn't know it at httpd.conf edit time. Many cases here : - You didn't map it. - You map it to the worker but in such case you have to triple URI mapping, one in Apache 2, another in mod_ajp, and of course a third in tomcat, and using 3 mapping was something you asked us to avoid yesterday ;) What about /examples/protected/ which may need to be authenticated - if we really want to support play nice with other apache modules, then we need to support authentication using apache modules. Then what if the webapp is reloaded with a different protected uri ? /examples/protected/ should use the Apache auth as any other 'native' Apache URL isn't it ? In such case we should exclude it from direct mod_ajp processing, it should case later in the hooks process. That's the main problem with jk/jk2 today, since we can be part of the various modules chain with JkMount for example :( So IMO any jk config MUST be JMX-like. May be. Of course we should have somewhere in the new module the configuration tree in whatever native format we could imagine, apr_map maybe or apr_xml_tree if existing. File format is not important - dynamic changes and updates are the important issue. - the configuration should be in Apache's config file, rather than some complex properties file +1 See above. Apache config file is clearly better than any arbitrary static jk-specific config file. And it does provide close integration - including auth* using any of apache modules, and anything you can dream of in terms of apache modules. However - it is very static, and I doubt this will change soon. Even with apache2, if you change the config ( add a webapp ) you need to restart apache ( which may be interesting if multithreaded and some module is using sessions). Not necessary. Nothing prevent us from doing something like this : Location /*.jsp AjpWorker myworker /Location Location /servlet/* AjpWorker myworker /Location And if the mod_xxx is able to discover the webapp attached to myworker, you got them redirected to the correct worker. And you lose the real integration into apache - which is the ability to use other modules. It was a simple example, and today the real integration with apache is pretty bad in jk/jk2, that's why I'd like to use something as simple as EnvVars to determine if an URL should be mapped by mod_ajp. There is way too many hooks handled by jk/jk2 today, more than complex modules like proxy or rewrite and it could be a reason why jk/jk2 didn't works well with Location/Directory/Alias and others Apache 2 directive... My point is that we have 2 use cases, one is strong integration, where you want to use apache modules, and the other is dynamic, where you want to deal with a server where apps are often deployed or changed. Well we could do the both : - strong integration using hard-coded settings in httpd.conf - dynamic integration using a sort of AjpMount Dynamic Worker1 but in such case you have to handle a specific URI mapping in mod_ajp. You just can't support both use cases with the same solution - if you try, it's a lose-lose situation. I agree, that's why we should first work on strong integration, at least for URL to worker part. Nothing prevent us for instance to be able to update worker (direct or cluster) caracteristics dynamically, put mapping is hardcoded. The real important feature in jk2 is the JMX emulation - I know almost nobody uses it :-). Well the code is too complex in jk2, and that's also why we need some cleanups. I agree. However starting from scratch without having a flexible design that takes into account the dynamicity of tomcat is bound to result in another chunk of complex code ( after some time ), or something inflexible ( mod_webapp ? ). mod_webapp was a good idea, which came too soon (APR mandatory before Apache 2 release)... Without having a common codebase and API that can be used outside Apache2? I like apache2, but keeping the options open is
Re: Some JK2 ideas v.3
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: I think you're mixing the Java side with the native side. I think the Java side should obviously use JMX to monitor what's going on with Tomcat. However, the native side will just recieve proprietary messages. We have to keep the native side as small and simple as possible to get into the HTTPD codebase. No, I'm only talking about the C side. Let's call it C-JMX. Instead of yet-another small and simple connector that grows out of control, it may be better to learn a lesson from java and apply it in C. Jk and Jk2 ( and mod_jserv ) all started small and simple, then got more and more features and fixes. If we start with just add custom proprietary messages for every feature we want to implement - the code will soon become very complex. Most of the messages are not in the critical path, so using a JMX model of get/set/event is reasonable. Monitoring and controlling the native code from java is IMO quite usefull and important by itself. Even Apache supports limited monitoring ( SNMP, mod_status, etc ). Ok. We'll see if I'm more convinced when you show your code ;) For now, I'm siding with Henri and his proposed solution. I'd like to heard some Apache 2 specialists here, may be some core HTTPD developpers since after all we're discussing an Apache 2.x module. I'll send an invitation to them in httpd-dev... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.3
Mladen Turk wrote:
Costin Manolache wrote
I can understand the jk2 object oriented C is considered
too complex.
True.
But I certainly can't agree on a design that is not modular
and doesn't support this basic requirement. We already have
mod_jserv and mod_webapp
- and a long history of rewrite from scratch to make it simpler
turning into far more complex code.
But we don't wish to write something modular and unlimitedly extendable.
Just the load-balancing-ajp13+ over tcp/ip connector, for Apache2.
Having that in mind, we have APR, and 'almost' a finite set of requirements,
without the need to 'think modular' or 'think cross-webserver'.
Lot of the code would be reusable, but it would mean that making a mod_jni
connector would mean to make a completely different project without some
common directory holding shareable code.
Also making any additional 'features' to the connector (like 'discovery'
etc.) would have to be made as such, and enabled during compile time, so
that the basic functionality remains as is. This means that we don't compile
everything and then use the config to either enable or disable features, but
rather make something like 'mpm concept' selectable at compile time.
Seriously - if you take away the JMX and support for other
servers - why not just use mod_jserv ?
No one prevents you of making mod_jmx that will allow entire Apache2 to be
maintainable trough JMX console, not only our module :).
A great idea, but probably something which should be a whole new module,
mod_jmx or mod_cmx (C Management Extension). I'm sure the HTTPD team
will be more than pleased to discuss this.
Regarding other servers you meant IIS (other are less then couple of
percent) probably (apache13 users can use jk). I would like to make the
'real' IIS6 filter that will go in the NT kernel's http.sys, have dynamic
thread pool and MMC snap-in, but that is something completely different. Few
things like config tree, ajp protocol and transport can be reused cause now
we have the APR that generalizes the OS layer.
If you wish to write a good Apache2 module or IIS filter, they have to be
different projects. Also being usable from admins point of view requires
that the apache module is configurable trough httpd.conf, and IIS trough
GUI. None of them uses JMX to configure the webserver thought.
I have on my dash-board for a long time a project that will make a TC as a
main web server, having Apache as a 'slave' for additional PHP and Perl
support, but that also is something completely different and questionably
usable.
After all mod_jk and
jk2 got complex because of additional requirements and
features that we wanted to implement - if we drop them then
we can just go back and use mod_jserv.
Think that the main problem is that we don't understand the JK2 code any
more, and that the modularity combined with crosswebserver became an
obstacle rather then a feature.
Yes, that's a perfect resume of the current situation.
I don't have problem with writing clean C to make something
JMX/CMXizable but it appears to add some complexity.
Just take a look at the actual code in jk2 :(
...
int JK_METHOD jk2_channel_setAttribute(jk_env_t *env,
jk_bean_t *mbean,
char *name, void *valueP)
{
jk_channel_t *ch = (jk_channel_t *)mbean-object;
char *value = valueP;
if (strcmp(debug, name) == 0) {
ch-mbean-debug = atoi(value);
}
else if (strcmp(disabled, name) == 0) {
ch-mbean-disabled = atoi(value);
if (ch-worker != NULL)
ch-worker-mbean-disabled = ch-mbean-disabled;
}
else {
if (ch-worker != NULL) {
return ch-worker-mbean-setAttribute(env, ch-worker-mbean,
name, valueP);
}
return JK_ERR;
}
return JK_OK;
}
...
The problem with C is there is no introspection helper so we have
to do many things by hand and it tend to 'offuscate' the real code.
I'd rather like simple C way:
int ajp_channel_setDebug(jk_channel_t * channel, int debuglevel);
int ajp_channel_setState(jk_channel_t * channel, int state);
int ajp_channel_open(jk_channel_t * channel);
int ajp_channel_close(jk_channel_t * channel);
int ajp_channel_read(jk_channel_t * channel, apr_pool_t * buf);
int ajp_channel_write(jk_channel_t * channel, apr_pool_t * buf);
int ajp_channel_hasInput(jk_channel_t * channel);
That's one of the reason I suggested a specific Apache 2.x module,
to follow the HTTPD dev team habbits which are still plain C.
May be a pre-requisite to go farther will be to discuss with them
what should be a CBean ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Invitation to HTTPD commiters in tomcat-dev
We're discussing on tomcat-dev about a new Apache to Tomcat Apache 2.x module. We'd like to see some of the core HTTPD developpers joins the discussion about the post JK/JK2 module. The goal of this new module : - 100% Apache 2.x module - Easy integration with existing Apache 2.x modules and directives, Location, Alias, Directory, Files, SetEnvIf... - Configuration done ONLY in httpd.conf to follow the usual Apache 2.x habbits. Well we need your precious expertise in this discussion. Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.6 release ? - session tracking cookie
Bill Barker wrote: - Original Message - From: Sandy McArthur [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, July 19, 2004 9:15 PM Subject: Re: mod_jk 1.2.6 release ? - session tracking cookie On Jul 19, 2004, at 8:43 AM, Henri Gomez wrote: And since I couldn't delay the release to long, we need a quick reply, so thanks to take a look at it. We've setup a current CVS checkout of mod_jk at http://sp27en1.nerdc.ufl.edu/login.do which is load balancing to our webmail cluster. If you constantly reload the page you'll see it's setting a new JSESSIONID cookie on every request. Could you send us you workers.properties ? Yup. Sending the cookie almost always fails to stick. Sending the jsessionid via URL-rewriting always sticks. So it does look like there is a bug with the lb cookie parsing. I can't see by looking at the code what it is however :(. I can probably find a machine that I can hook up with the HEAD code and lb to see what is going wrong, but I can't promise when. If you feel like putting more work into this, adding 'fprintf(stderr,...)' statements should go to the Apache error_log. I've got such settings here, with 2 TC 3.3.2. Where did you want me put fprint ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.3
Henri Gomez wrote: Mladen Turk wrote: The AJP13 protocol will have to be enhanced (or better enabled) to use the 'Service channel' and 'Data Filter'. It is not necessary to define all Service channel modes like server topology, or server readiness, neither to define all the Data Filter modes like cryptography or compression. I was thinking of something like 'extensions' to the protocol, meaning that one can extend the protocol to some desired level. Yes. My initial idea for AJP/1.4 wass to mix on the same wire request forwaring which is the core functionnality of AJP/1.3 with system messaging. - Service channel is a channel to send/received update between Apache and Tomcats : - Negociation between Apache and Tomcat. * Should we use an authentification scheme between Apache and Tomcat (ajp1.3 make that Tomcat trust any Web server caming via AJP13). * Should we compress the requests/replies * Should we crypt the requests/replies. - Web Applications state updates : * a Web Application is added * a Web Application is removed - Updates in cluster configurations : * worker1 was handling 25% of total load, now it could handle 35%. * worker2 in cluster is down for maintenance * Apache 2 could use worker3 for this cluster, it could reach it at IP/PORT Ideally since we could have a cluster of Apache WebServer linked to a cluster of Tomcat ServletEngines, and that member could enter or exit these 2 clusters we should have something using Multicast (ideally a native JavaGroups) for both side. With such the configuration in both Web and Tomcat clusters will be to enter a Service Channel where all members will get all the services messages and handle them accordingly ? What about multicast support in APR ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Some JK2 ideas v.3
-Original Message- From: Henri Gomez Ideally since we could have a cluster of Apache WebServer linked to a cluster of Tomcat ServletEngines, and that member could enter or exit these 2 clusters we should have something using Multicast (ideally a native JavaGroups) for both side. Wow, you've push it to the limit :) With such the configuration in both Web and Tomcat clusters will be to enter a Service Channel where all members will get all the services messages and handle them accordingly ? What about multicast support in APR ? Each node would need both server and client listeners, so they can exchange service messages. But I'm not sure that I wish to see that in the core itself. It brings an extra complexity that is needed in 'not-an-everyday usage'. Something like should either be a different project or at least manageable at compile time. MT. smime.p7s Description: S/MIME cryptographic signature
Re: Some JK2 ideas v.3
Mladen Turk wrote: -Original Message- From: Henri Gomez Ideally since we could have a cluster of Apache WebServer linked to a cluster of Tomcat ServletEngines, and that member could enter or exit these 2 clusters we should have something using Multicast (ideally a native JavaGroups) for both side. Wow, you've push it to the limit :) With such the configuration in both Web and Tomcat clusters will be to enter a Service Channel where all members will get all the services messages and handle them accordingly ? What about multicast support in APR ? Each node would need both server and client listeners, so they can exchange service messages. But I'm not sure that I wish to see that in the core itself. It brings an extra complexity that is needed in 'not-an-everyday usage'. Something like should either be a different project or at least manageable at compile time. No this settings will be for mod_ajp 2.x :) We should focus now on mod_ajp 1.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Nick Kew wrote: On Tue, 20 Jul 2004, Henri Gomez wrote: We're discussing on tomcat-dev about a new Apache to Tomcat Apache 2.x module. We'd like to see some of the core HTTPD developpers joins the discussion about the post JK/JK2 module. As a startingpoint, how about telling us what tomcat needs that mod_proxy and friends don't provide? In mod_jk/jk2, there is support for load-balancing and fault-tolerance and it's a key feature. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Satish Rajaraman/IN/ABNAMRO/NL is out of the office.
I will be out of the office starting 07/03/2004 and will not return until 07/27/2004. I will respond to your message when I return. --- This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorised use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. ABN AMRO Bank N.V. (including its group companies) shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. ABN AMRO Bank N.V. (or its group companies) does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas
Hi, A good number desparately want NTLM-based authentication. [They like the single-sign on for Windows clients, but they love the notion of better security than clear-text name/password, etc, without having to buy a server certificate or use HTTPS on their intranet.] If Apache 2 had a stable module for this (whether or not it was from the ASF itself), I would think this would be a good step to get these folk to shift to Apache. then shift them - this module is available since first Apache2 days: http://www.gknw.net/development/apache/httpd-2.0/win32/modules/mod_auth_sspi-1.0.1-2.0.49.zip and also for Apache 2.1: http://www.gknw.net/development/apache/httpd-2.1-dev/win32/modules/mod_auth_sspi-1.0.1-2.1-dev.zip Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: port number at runtime
Hi, It will be very usefull if the port number on which the SSL and Http non-ssl ports are running, is available runtime. (Ex:- 8080 and 8443). Is it possible? The int getPort() method of the CoyoteConnector class returns the port number but its not accessible at runtime. If there is a sendRedirect() method in some jsp, where one wants to redirect from http to say https, then the port number must be known in advance. So there is a need for such an API. request.getServerPort() see the jsp snoop example. Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Nick Kew wrote: On Tue, 20 Jul 2004, Henri Gomez wrote: [ chopped tomcat-dev because that bounces my mail ] As a startingpoint, how about telling us what tomcat needs that mod_proxy and friends don't provide? In mod_jk/jk2, there is support for load-balancing and fault-tolerance and it's a key feature. Good start. I'm guessing you're ahead of me here, and your reason for posting to [EMAIL PROTECTED] is that you can see that implementing these capabilities will be of general interest to more than just tomcat users? Back to tomcat-dev + httpd-dev. Well this kind of features will be usefull for more than just Tomcat users of course. Our main interest in inviting httpd-dev members to tomcat-dev list is to see if common interest could be shared and of course take recommandations for the jk/jk2 successor. My gut feeling would be to keep this properly modular. Let mod_proxy be the core of it, and implement load-balancing and fault-tolerance in additional modules. As a matter of fact, one of my wishlist-projects is a connection-pooling module for backend HTTP connections in a proxy. That might actually be the same as your project. And what about using AJP/1.3 instead of HTTP for connection to tomcat ?) In fact mod_proxy could be a good starting point for learning how relying request from Apache 2.x to Tomcat for what we called actually mod_ajp, to avoid confusion with jk/jk2. But : - If you add load-balancing/fault-tolerance and AJP 1.3 support in mod_proxy you'll have about 99% of the current functionalities of jk 1.2.x. We discussed also the need for some dynamic mapping and topology discovery/update (between Apache and Tomcats Clusters). And in fine, we like to have some JMX like functionnalities in Apache 2, in our case CMX for C Management Extension, a way to update Apache 2.x configuration while the server is running... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30206] New: - Unexpected bug when use phone browser request redirect page
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=30206. 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=30206 Unexpected bug when use phone browser request redirect page Summary: Unexpected bug when use phone browser request redirect page Product: Tomcat 5 Version: 5.0.25 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Dear all, I'm not sure is this bug? but If we use phone browser browse redirect page by some mobile browser it isn't work: File: index.jsp % response.sendRedirect(../login.jsp); % I check by use telnet to my server and write HTTP request to see the response below: GET /wap/index.jsp HTTP/1.0 HOST: myserver:8080 HTTP/1.1 302 Moved Temporarily Set-Cookie: JSESSIONID=F2CCA24F97C6990CB96354EE4DC398BD; Path=/wap Location: http://myserver:8080/wap/../login.jsp Content-Type: text/html Content-Length: 0 Date: Tue, 20 Jul 2004 11:48:20 GMT Server: Apache-Coyote/1.1 Connection: close I think that phone browser doesn't support this Location url : http://myserver:8080/wap/../login.jsp, but on Tomcat 4.x this file will generate header in absolute url like this below and it work: HTTP/1.1 302 Moved Temporarily Location: http://myserver:8080/wap/login.jsp Content-Length: 0 Date: Tue, 20 Jul 2004 12:08:37 GMT Server: Apache-Coyote/1.1 Connection: close Could you advise which Tomcat 5.x can resolve this unexpected problem. I know that Tomcat 5.x have performance optimization and more efficiently features. Thank you. Kumphol Rattanachanchai - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30206] - Unexpected bug when use phone browser request redirect page
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=30206. 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=30206 Unexpected bug when use phone browser request redirect page [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-07-20 12:35 --- If you want to support broken clients, I suggest modifying the Tomcat code (normalizing the URL before setting the location header seems a possibility). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SPAM on the list - candidates for unsubscribe
Hi, I dont know how all others deal with all the SPAM, but I can only say that I'm now tired of adding just another rule for my SPAM killer every day. What I really cant get is that this is the only list with that problem! If then all the robots are unable to avoid re-subscribing of the spam assholes - and seems that's the case with this list here - then we should probably think about unsubcribing all, and restart with a human which checks the subscritions and kill the automatic subscribe. I really would like to continue following the JTC development - but I've no time for fishing the 5 human mails out of the 50 autoresonder and spam mails every day! here are candidates I have now about 10 times asked for unsubscribe: From: DirectXtras [EMAIL PROTECTED] From: [EMAIL PROTECTED] From: Autoresponder [EMAIL PROTECTED] and they get subscribed again and again; I guess bad thing is that they dont subscribe with @directxtras.com but with another name just to get the email addresses from the other subscibers; so we should also think about another list structure which makes the personal emails invisibable - anyway better since it avoids any direct posts then; Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SPAM on the list - candidates for unsubscribe
Hi, And most times you reply, I say the same things: - I don't get auto-responses from those people, and if others do I don't know how they deal with them but they sure don't complain on a regular basis ;) - I try to unsubscribe them (and the past few times, add them to the deny list as well) every single time you ask Ideas for different moderation and subscriptions schemes have been discussed numerous times on [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], and other lists -- you may wish to complain there. Yoav Shapira Millennium Research Informatics -Original Message- From: Günter Knauf [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 9:08 AM To: [EMAIL PROTECTED] Subject: SPAM on the list - candidates for unsubscribe Hi, I dont know how all others deal with all the SPAM, but I can only say that I'm now tired of adding just another rule for my SPAM killer every day. What I really cant get is that this is the only list with that problem! If then all the robots are unable to avoid re-subscribing of the spam assholes - and seems that's the case with this list here - then we should probably think about unsubcribing all, and restart with a human which checks the subscritions and kill the automatic subscribe. I really would like to continue following the JTC development - but I've no time for fishing the 5 human mails out of the 50 autoresonder and spam mails every day! here are candidates I have now about 10 times asked for unsubscribe: From: DirectXtras [EMAIL PROTECTED] From: [EMAIL PROTECTED] From: Autoresponder [EMAIL PROTECTED] and they get subscribed again and again; I guess bad thing is that they dont subscribe with @directxtras.com but with another name just to get the email addresses from the other subscibers; so we should also think about another list structure which makes the personal emails invisibable - anyway better since it avoids any direct posts then; Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Workers2.properties.sample
Using the isapi_redirector2.dll file, and this this workers2.properties, the URI for /calendar doesn't work if I Uncomment the group= line. This leads me to believe the group= line should contain lb:lb and not lb as shown in the /examples URI in the referenced file. If this is indeed the case, someone should update the sample file. [shm] info=Scoreboard. Requried for reconfiguration and status with multiprocess servers. file=anon # Defines a load balancer named lb. Use even if you only have one machine. [lb:lb] # Example socket channel, override port and host. [channel.socket:localhost:8009] port=8009 host=127.0.0.1 # define the worker [ajp13:localhost:8009] channel=channel.socket:localhost:8009 group=lb [status:] info=Status worker, displays runtime information [uri:/calendar/*] info=Connect Daily Web calendar #group=lb #[uri:/jkstatus/*] #info=The Tomcat /jkstatus handler #group=status: George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SPAM on the list - candidates for unsubscribe
From what lands in my mailbox, this list has a strange propensity of subscriptions from bizarre auto-responders. Generally, they aren't in English, and appear to be the customer support departments of various miscellaneous European companies. Who signs them up? Why? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.6 release ? - session tracking cookie
On Jul 20, 2004, at 5:27 AM, Henri Gomez wrote: Could you send us you workers.properties ? attached. workers.properties Description: Binary data If you feel like putting more work into this, adding 'fprintf(stderr,...)' statements should go to the Apache error_log. Where did you want me put fprint ? Let us know where you want them and we'll test that code too. Sandy McArthur smime.p7s Description: S/MIME cryptographic signature
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: And what about using AJP/1.3 instead of HTTP for connection to tomcat ?) In all my deployments of tomcat I have never seen the point of a custom protocol that did exactly what HTTP does, so all my tomcat deployments are all HTTP, with a simple mod_proxy frontend. Even the get Apache to server static content feature wasn't enough of a drawcard, as proper HTTP cache handling and a suitable cache solved this problem. It was far more important for me to arrange the web application as a self contained unit - I would rather be more tidy with an install at the expense of a slightly higher load, than sacrifice a clean install to save some cycles. - If you add load-balancing/fault-tolerance and AJP 1.3 support in mod_proxy you'll have about 99% of the current functionalities of jk 1.2.x. We discussed also the need for some dynamic mapping and topology discovery/update (between Apache and Tomcats Clusters). Proxy has a placeholder in it that says put the code to make decision about load balancing etc here - all that is needed is a hook and a module proxy_loadbalancing.c to make it happen. And in fine, we like to have some JMX like functionnalities in Apache 2, in our case CMX for C Management Extension, a way to update Apache 2.x configuration while the server is running... This is possibly a whole separate project in itself. I have been meaning to work on a get-apache-config-out-of-ldap extension for a while, what it really should be is get apache config out of wherever, but this should be an Apache wide thing, not limited to a single module or technology. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Some JK2 ideas
I actually built this yesterday upon rediscovering it -- and it seems to work fine. Unfortunately: 1. The licensing is unclear. 2. There appears to be no active maintenance or support of this module. I'm thus more than a little reluctant to put too many eggs in this basket. -- Jess Holle Günter Knauf wrote: Hi, A good number desparately want NTLM-based authentication. [They like the single-sign on for Windows clients, but they love the notion of better security than clear-text name/password, etc, without having to buy a server certificate or use HTTPS on their intranet.] If Apache 2 had a stable module for this (whether or not it was from the ASF itself), I would think this would be a good step to get these folk to shift to Apache. then shift them - this module is available since first Apache2 days: http://www.gknw.net/development/apache/httpd-2.0/win32/modules/mod_auth_sspi-1.0.1-2.0.49.zip and also for Apache 2.1: http://www.gknw.net/development/apache/httpd-2.1-dev/win32/modules/mod_auth_sspi-1.0.1-2.1-dev.zip Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Henri Gomez wrote: And what about using AJP/1.3 instead of HTTP for connection to tomcat ?) In all my deployments of tomcat I have never seen the point of a custom protocol that did exactly what HTTP does, so all my tomcat deployments are all HTTP, with a simple mod_proxy frontend. Well AJP/1.3 save cycle in tomcat avoiding it to re-decode headers for examples. It forward also the SSL infos if needed. And AJP/1.3 use persistant connections so it safe cycle also. jk was designed a long time ago so may be mod_proxy allready support persistant connections. Even the get Apache to server static content feature wasn't enough of a drawcard, as proper HTTP cache handling and a suitable cache solved this problem. It was far more important for me to arrange the web application as a self contained unit - I would rather be more tidy with an install at the expense of a slightly higher load, than sacrifice a clean install to save some cycles. - If you add load-balancing/fault-tolerance and AJP 1.3 support in mod_proxy you'll have about 99% of the current functionalities of jk 1.2.x. We discussed also the need for some dynamic mapping and topology discovery/update (between Apache and Tomcats Clusters). Proxy has a placeholder in it that says put the code to make decision about load balancing etc here - all that is needed is a hook and a module proxy_loadbalancing.c to make it happen. Great. And if you handle in the proxy_loadbalancing.c the JSESSION_ID, (sticky session) to map next requests to the tomcat who set it, you'll have everything needed. Of course you should also handle some mixed cases, like full round-robin, and sticky round-robin. The idea is interesting. And in fine, we like to have some JMX like functionnalities in Apache 2, in our case CMX for C Management Extension, a way to update Apache 2.x configuration while the server is running... This is possibly a whole separate project in itself. I have been meaning to work on a get-apache-config-out-of-ldap extension for a while, what it really should be is get apache config out of wherever, but this should be an Apache wide thing, not limited to a single module or technology. Well LDAP could be use for configuration outside a file. JMX/CMX goes a bit farther since it let you update some characteristics at runtime. But I agree that providing a JMX/CMX facade to Apache 2.x modules will be a good starting point. Costin will certainly clarify this point with you. In fine the discussed mod_ajp module should detect topology change in a second phase to learn for example that a tomcat in a cluster started/stopped a web application, so next requests could be redirected to another tomcat in the cluster. Also you should be able to update the load factor for each tomcat, may be having a load factor by Webapplication. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.3
Mladen Turk wrote: But we don't wish to write something modular and unlimitedly extendable. Just the load-balancing-ajp13+ over tcp/ip connector, for Apache2. Having that in mind, we have APR, and 'almost' a finite set of requirements, without the need to 'think modular' or 'think cross-webserver'. I understand this, and it is a good idea. I'm ok to drop multi server and multiple protocols or extensible and jni. The only point I strongly disagree is droping the monitoring and runtime re-configuration. Tomcat is a dynamic server, people are using it to deploy and modify webapps all the time - editing httpd.conf and restarting the server on each change is not the right solution. Also making any additional 'features' to the connector (like 'discovery' etc.) would have to be made as such, and enabled during compile time, so that the basic functionality remains as is. This means that we don't compile everything and then use the config to either enable or disable features, but rather make something like 'mpm concept' selectable at compile time. Well, I also disagree with this :-), enabling/disabling discovery or other features should be done at runtime. I don't like too many ./configure options. Seriously - if you take away the JMX and support for other servers - why not just use mod_jserv ? No one prevents you of making mod_jmx that will allow entire Apache2 to be maintainable trough JMX console, not only our module :). Unfortunately - adding monitoring and runtime reconfiguration requires a certain design. Some parts of apache can be monitored, but not much ( certainly not the modules - unless you hack something and look in their private data structures ). Reconfiguration is even harder without having it in the design. As I said, what you describe - basic protocol only and only apache - is already available in mod_jserv, it just needs porting to apache2. Why would you want to write another module doing the same thing ? If you wish to write a good Apache2 module or IIS filter, they have to be different projects. Also being usable from admins point of view requires that the apache module is configurable trough httpd.conf, and IIS trough GUI. None of them uses JMX to configure the webserver thought. None of the web servers support the dynamic webapp adding or clustering and all the feture that tomcat supports. I think monitoring and reconfiguration is a must feature for a servlet container, and that also means the web server connector should have basic support for it. Think that the main problem is that we don't understand the JK2 code any more, and that the modularity combined with crosswebserver became an obstacle rather then a feature. No problem, drop both ( and multiple protocol as well ). But don't drop features that actually matter. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Manni Wood wrote: I very rarely post to this list, but I've been building web sites for over eight years, and want to chime in. In my experience building web sites for Fortune 500 companies (some of them Fortune 50 companies), the get Apache to serve static content while Tomcat only takes care of servlets and JSPs feature is a *huge* draw. But do you know what the biggest draws of all would be to any Apache 2 module that connects to tomcat? 1. Fantastic documentation. I cannot stress this enough. Hell, I'd even volunteer for this part. The module iteself could be poorly implemented, problematic to compile, and have truly silly defaults, but if it was incredibly well and clearly documented, I'd use it over mod_jk2 starting tomorrow. The documentation is bad, we all agree on this and when I take a look at any Apache module the doc is way better. But the lack of documentation is also due to the complexity put in jk/jk2 after years of features additions without re-factory. Also jk and jk2 inherited this, was designed to work with Apache 1.3, 2.0, IIS, iPlanet it supports also Domino and this cross compat stuff made it a very different Apache module. 2. Barring my comments in 1, a module that really and truly works, and has useful out-of-the-box (or freshly-compiled) defaults. (Maybe even, by defalt, *only* passes servelt/JSP requests to tomcat, and lets Apache handle the rest automatically.) Well documentation and good default are also requested by tomcat-dev main commiters. It's now time to refactor and redesign it with Apache 2.x (APR/AP) in mind to follow Apache 2.x admins habbits and try to make something simpler. We came on httpd-dev for advice from experts, and may be an extended mod_proxy could be the solution. But we also want to keep the AJP/1.3 and AJP/1.4 protocols since it works well and so a pure HTTP proxy is only part of the game. - Could mod_proxy be open to support AJP/1.x as tomcat connections ? - Should we learn from mod_proxy to redesign something using AJP ? Many questions which need experts answers... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_lb_worker.c
hgomez 2004/07/20 07:56:40
Modified:jk/native/common jk_lb_worker.c
Log:
More debug infos around LB.
Revision ChangesPath
1.21 +8 -1 jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c
Index: jk_lb_worker.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- jk_lb_worker.c15 Jul 2004 07:04:15 - 1.20
+++ jk_lb_worker.c20 Jul 2004 14:56:40 - 1.21
@@ -296,6 +296,9 @@
jk_b_set_buffer_size(s-reco_buf, DEF_BUFFER_SZ);
jk_b_reset(s-reco_buf);
s-reco_status = RECO_INITED;
+jk_log(l, JK_LOG_DEBUG, Into jk_endpoint_t::service sticky_session=%d\n,
+ p-worker-sticky_session);
+
while(1) {
worker_record_t *rec = get_most_suitable_worker(p-worker, s,
attempt++);
int rc;
@@ -306,6 +309,10 @@
s-jvm_route = jk_pool_strdup(s-pool, rec-name);
rc = rec-w-get_endpoint(rec-w, end, l);
+
+jk_log(l, JK_LOG_DEBUG, Into jk_endpoint_t::service worker=%s
jvm_route=%s rc=%d\n,
+ rec-name, s-jvm_route, rc);
+
if(rc end) {
int src = end-service(end, s, l, is_recoverable);
end-done(end, l);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hi
Your file is attached. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.3
Henri Gomez wrote: The AJP13 protocol will have to be enhanced (or better enabled) to use the 'Service channel' and 'Data Filter'. It is not necessary to define all Service channel modes like server topology, or server readiness, neither to define all the Data Filter modes like cryptography or compression. I was thinking of something like 'extensions' to the protocol, meaning that one can extend the protocol to some desired level. Yes. My initial idea for AJP/1.4 wass to mix on the same wire request forwaring which is the core functionnality of AJP/1.3 with system messaging. - Service channel is a channel to send/received update between Apache and Tomcats : - Negociation between Apache and Tomcat. * Should we use an authentification scheme between Apache and Tomcat (ajp1.3 make that Tomcat trust any Web server caming via AJP13). * Should we compress the requests/replies * Should we crypt the requests/replies. - Web Applications state updates : * a Web Application is added * a Web Application is removed - Updates in cluster configurations : * worker1 was handling 25% of total load, now it could handle 35%. * worker2 in cluster is down for maintenance * Apache 2 could use worker3 for this cluster, it could reach it at IP/PORT This sound like a lot of features. I'm sure others will be added to the list by other people. That is my concern - it seems the assumption is this will be a very simple module, so there is no need for modularity or a flexible design. On the other side, just like in all other it's going to be very simple cases, features will keep piling. It's one thing to have just apache2 module and ajp13 ( and nothing more), another thing to have all the above. The real problem is: 1. figuring the list of features. - I agree multiple protocols ( incl jni) and multiple servers should be droped. - We seem to agree on having cluster reconfiguration feature. - I'm not sure if we agree or not on dynamic add/remove of webapps. - It seems I'm alone in wanting monitoring and finer reconfiguration. - we agree on strong integration with the server - I'm not sure about about the add/remove of webapps versus strong integration - I haven't seen any answer on how they can work togheter, it seems Mladen solves this by removing add remove webapps, which IMO is bad. I just don't know how you can have both at the same time - the only solution I found so far is to have 2 operating modes. 2. design. It seems a lot of people believe this will stay simple and there is no need for a flexible design (i.e. components, etc ). If it is a clear understanding that the feature list will be frozen - i.e. if you want more features, you'll need to write a new module from scratch and not reuse anything from this - then it may work, but I never seen this happening in open source. If C-Mbeans are too complicated - then maybe we can use GObject ( from gnome ) or XPCom components ( from mozilla ) ( or some subset of it). But please, don't start another simple project that in a year will have to be rewritten. Object oriented programming does have some value:-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some JK2 ideas v.3
Henri Gomez wrote: The AJP13 protocol will have to be enhanced (or better enabled) to use the 'Service channel' and 'Data Filter'. It is not necessary to define all Service channel modes like server topology, or server readiness, neither to define all the Data Filter modes like cryptography or compression. I was thinking of something like 'extensions' to the protocol, meaning that one can extend the protocol to some desired level. Yes. My initial idea for AJP/1.4 wass to mix on the same wire request forwaring which is the core functionnality of AJP/1.3 with system messaging. - Service channel is a channel to send/received update between Apache and Tomcats : - Negociation between Apache and Tomcat. * Should we use an authentification scheme between Apache and Tomcat (ajp1.3 make that Tomcat trust any Web server caming via AJP13). * Should we compress the requests/replies * Should we crypt the requests/replies. - Web Applications state updates : * a Web Application is added * a Web Application is removed - Updates in cluster configurations : * worker1 was handling 25% of total load, now it could handle 35%. * worker2 in cluster is down for maintenance * Apache 2 could use worker3 for this cluster, it could reach it at IP/PORT This sound like a lot of features. I'm sure others will be added to the list by other people. That is my concern - it seems the assumption is this will be a very simple module, so there is no need for modularity or a flexible design. On the other side, just like in all other it's going to be very simple cases, features will keep piling. It's one thing to have just apache2 module and ajp13 ( and nothing more), another thing to have all the above. The real problem is: 1. figuring the list of features. - I agree multiple protocols ( incl jni) and multiple servers should be droped. - We seem to agree on having cluster reconfiguration feature. - I'm not sure if we agree or not on dynamic add/remove of webapps. - It seems I'm alone in wanting monitoring and finer reconfiguration. - we agree on strong integration with the server - I'm not sure about about the add/remove of webapps versus strong integration - I haven't seen any answer on how they can work togheter, it seems Mladen solves this by removing add remove webapps, which IMO is bad. I just don't know how you can have both at the same time - the only solution I found so far is to have 2 operating modes. 2. design. It seems a lot of people believe this will stay simple and there is no need for a flexible design (i.e. components, etc ). If it is a clear understanding that the feature list will be frozen - i.e. if you want more features, you'll need to write a new module from scratch and not reuse anything from this - then it may work, but I never seen this happening in open source. If C-Mbeans are too complicated - then maybe we can use GObject ( from gnome ) or XPCom components ( from mozilla ) ( or some subset of it). But please, don't start another simple project that in a year will have to be rewritten. Object oriented programming does have some value:-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: jk was designed a long time ago so may be mod_proxy allready support persistant connections. Persistence will happen on the backend on the condition there was persistence on the frontend. Generally the networks between backend and frontend are fast enough that connection setup is not a problem - a bigger problem is having expensive backend processes hanging around attached to a persistent connection that is not being used (assuming these connections are held by a tomcat thread of course, which may or may not be the case, not sure how tomcat is built internally). Great. And if you handle in the proxy_loadbalancing.c the JSESSION_ID, (sticky session) to map next requests to the tomcat who set it, you'll have everything needed. Sticky sessions has been on my list of things to support for ages - perhaps a proxy_sticky.c module could take a single parameter (the name of the parameter and/or cookie) and keep track of which server served it. If you had redundant frontends you might have a mechanism to keep track of which server is handling which session stored in a shared mechanism. A separate module might keep track of which tomcat servers are up or down, removing a server from the list of available servers on certain events (connection refused, error 4xx, 5xx, whatever). Well LDAP could be use for configuration outside a file. JMX/CMX goes a bit farther since it let you update some characteristics at runtime. But I agree that providing a JMX/CMX facade to Apache 2.x modules will be a good starting point. Costin will certainly clarify this point with you. In fine the discussed mod_ajp module should detect topology change in a second phase to learn for example that a tomcat in a cluster started/stopped a web application, so next requests could be redirected to another tomcat in the cluster. Also you should be able to update the load factor for each tomcat, may be having a load factor by Webapplication. In theory this kind of thing should not be limited to tomcat only, but to web applications (whether PHP, whatever) in general. Perhaps a mechanism that allows the backend to connect to the frontend and say status has changed, I am offering webapp XXX now, so count me into the pool. Or a mechanism for the frontend to poll the characteristics of the backend so that it can autolearn what webapp can be found where (has the advantage of not requiring a special backend module, apart from a magic URL on the backend giving relevant the information) This opens up some interesting possiblities for virtual mappings. Something like this: ProxyPass /myWebapp virtual://myWebbapp (or something) Where proxy can hand out the request to a backend that has recently said hi proxy, I serve myWebapp, feel free to contact me to fulfil a request. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Henri Gomez wrote: And what about using AJP/1.3 instead of HTTP for connection to tomcat ?) In all my deployments of tomcat I have never seen the point of a custom protocol that did exactly what HTTP does, so all my tomcat deployments are all HTTP, with a simple mod_proxy frontend. Even the get Apache to server static content feature wasn't enough of a drawcard, as proper HTTP cache handling and a suitable cache solved this problem. It was far more important for me to arrange the web application as a self contained unit - I would rather be more tidy with an install at the expense of a slightly higher load, than sacrifice a clean install to save some cycles. - If you add load-balancing/fault-tolerance and AJP 1.3 support in mod_proxy you'll have about 99% of the current functionalities of jk 1.2.x. We discussed also the need for some dynamic mapping and topology discovery/update (between Apache and Tomcats Clusters). Proxy has a placeholder in it that says put the code to make decision about load balancing etc here - all that is needed is a hook and a module proxy_loadbalancing.c to make it happen. And in fine, we like to have some JMX like functionnalities in Apache 2, in our case CMX for C Management Extension, a way to update Apache 2.x configuration while the server is running... This is possibly a whole separate project in itself. I have been meaning to work on a get-apache-config-out-of-ldap extension for a while, what it really should be is get apache config out of wherever, but this should be an Apache wide thing, not limited to a single module or technology. I think using mod_proxy is acceptable for our most important needs, as the Tomcat HTTP/1.1 connnector has acceptable performance. We would need: - JSESSIONID stickiness - persistent connections support - (and of course) load balancing (with a static worker list) with failover - bonus points for auto retry (if the request allows it) to another node when recieving a 503 status SSL client-cert support (which I have no idea how to implement with mod_proxy, or maybe I missed something) and more generally, support for doing auth on the native webserver doesn't seem to be there, which is a problem. For ease of use, we need this Tomcat policy (actually, it's not Tomcat specific, obviously) to be included in the Apache source distribution, and ready to enable. I would like a more custom solution better, but if that's the only acceptable solution for you (and you accept the module into the Apache ;) ), then I'm ok with it. In this case, we would need another, more complex connector for the advanced use cases, but we would have addressed the needs of the majority of users. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WebappClassLoader.getURLs Bug!
In Tomcat 4.1.x, I discovered that RMI calls from Tomcat failed when the
any of the full file paths of the web app jars contained a space (' ')
character.
At the time, I was told this would be fixed in Tomcat 5 and to work
around it in Tomcat 4.1.x, which I did.
Unfortunately, now that I've moved to Tomcat 5, I discover that the bug
is still quite present. There is now a nice getURI() method along with
the previous getURL() method. Unfortunately, getURLs() does not use
getURI( file ).toURL() or any such as it would need to for the RMI
runtime's sake (as it calls getURLs()).
I can clearly patch WebappClassLoader.getURLs() to make such calls
myself, but:
1. I'm left wondering about the broader implications of doing just this.
* In Tomcat 4.1.x, I changed getURL() to do
canonicalFile.toURI().toURL() under Java 1.4 and a hand
coded equivalent in previous JVMs.
* This works quite robustly in my experience, but I'm left
wondering what the overall best, safest, and most performant
fix is.
2. I don't want to keep having to maintain my own fix. An overall
optimal fix should be integrated into Tomcat 5 so that this issue
ceases to be an issue for everyone using Tomcat.
--
Jess Holle
Re: Invitation to HTTPD commiters in tomcat-dev
Well, the mod_proxy + enhancements for sticky session + enhancements for passing auth info sounds reasonable - and if nobody wants the JMX support, then maybe we won't need to write a new connector anyway :-) Remy will be happy - we'll only use the http connector. Costin Graham Leggett wrote: Henri Gomez wrote: jk was designed a long time ago so may be mod_proxy allready support persistant connections. Persistence will happen on the backend on the condition there was persistence on the frontend. Generally the networks between backend and frontend are fast enough that connection setup is not a problem - a bigger problem is having expensive backend processes hanging around attached to a persistent connection that is not being used (assuming these connections are held by a tomcat thread of course, which may or may not be the case, not sure how tomcat is built internally). Great. And if you handle in the proxy_loadbalancing.c the JSESSION_ID, (sticky session) to map next requests to the tomcat who set it, you'll have everything needed. Sticky sessions has been on my list of things to support for ages - perhaps a proxy_sticky.c module could take a single parameter (the name of the parameter and/or cookie) and keep track of which server served it. If you had redundant frontends you might have a mechanism to keep track of which server is handling which session stored in a shared mechanism. A separate module might keep track of which tomcat servers are up or down, removing a server from the list of available servers on certain events (connection refused, error 4xx, 5xx, whatever). Well LDAP could be use for configuration outside a file. JMX/CMX goes a bit farther since it let you update some characteristics at runtime. But I agree that providing a JMX/CMX facade to Apache 2.x modules will be a good starting point. Costin will certainly clarify this point with you. In fine the discussed mod_ajp module should detect topology change in a second phase to learn for example that a tomcat in a cluster started/stopped a web application, so next requests could be redirected to another tomcat in the cluster. Also you should be able to update the load factor for each tomcat, may be having a load factor by Webapplication. In theory this kind of thing should not be limited to tomcat only, but to web applications (whether PHP, whatever) in general. Perhaps a mechanism that allows the backend to connect to the frontend and say status has changed, I am offering webapp XXX now, so count me into the pool. Or a mechanism for the frontend to poll the characteristics of the backend so that it can autolearn what webapp can be found where (has the advantage of not requiring a special backend module, apart from a magic URL on the backend giving relevant the information) This opens up some interesting possiblities for virtual mappings. Something like this: ProxyPass /myWebapp virtual://myWebbapp (or something) Where proxy can hand out the request to a backend that has recently said hi proxy, I serve myWebapp, feel free to contact me to fulfil a request. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: It's now time to refactor and redesign it with Apache 2.x (APR/AP) in mind to follow Apache 2.x admins habbits and try to make something simpler. We came on httpd-dev for advice from experts, and may be an extended mod_proxy could be the solution. But we also want to keep the AJP/1.3 and AJP/1.4 protocols since it works well and so a pure HTTP proxy is only part of the game. I think any module that speaks ajp/1.X should be called mod_ajp, keeps things simple and clean. - Could mod_proxy be open to support AJP/1.x as tomcat connections ? I don't think mod_proxy should support ajp, rather a dedicated ajp module should. But I'm still not convinced a separate protocol is needed when HTTP exists and is supported already. The httpd serves the static content feature can be implemented through extending ProxyPass to support regular expressions, for example: ProxyPass /myWebapp/*.jsp http://tomcat/myWebapp/ I'm not sure if persistent connections over and above HTTP/1.1 keepalives is that useful. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
RE: WebappClassLoader.getURLs Bug!
Hi, Unfortunately, now that I've moved to Tomcat 5, I discover that the bug is still quite present. There is now a nice getURI() method along with the previous getURL() method. Unfortunately, getURLs() does not use getURI( file ).toURL() or any such as it would need to for the RMI runtime's sake (as it calls getURLs()). The getURI method returns a URL object, not a URI object, as the latter is JDK 1.4-only and we still officially support building and running on JDK 1.3. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: In all my deployments of tomcat I have never seen the point of a custom protocol that did exactly what HTTP does, so all my tomcat deployments are all HTTP, with a simple mod_proxy frontend. Even the get Apache to server static content feature wasn't enough of a drawcard, as proper HTTP cache handling and a suitable cache solved this problem. It was far more important for me to arrange the web application as a self contained unit - I would rather be more tidy with an install at the expense of a slightly higher load, than sacrifice a clean install to save some cycles. There is a bit more - we want to be able to have Apache authenticate and pass this info to tomcat for example. I don't know if this can be done with mod_proxy ( maybe have it add an extra header - but that may have security problems ). And in fine, we like to have some JMX like functionnalities in Apache 2, in our case MX for C Management Extension, a way to update Apache 2.x configuration while the server is running... This is possibly a whole separate project in itself. I have been meaning to work on a get-apache-config-out-of-ldap extension for a while, what it really should be is get apache config out of wherever, but this should be an Apache wide thing, not limited to a single module or technology. The actual problem is how to push config changes without restarting the server. Some changes obviously require restart, but chaning mappings for example should be dynamic. In MPM multithreaded mode some modules may cache session information - frequent restarts are going to be more difficult than with single threaded server. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Wayne Frazee wrote: Please pardon me for attempting to marshall the obvious however what is the advantage of AJP/1.x over HTTP? - Persistant connections, mod_jk use a pool of socket connections to avoid reopening connections between Apache and Tomcats. You could set socket timeout to make these sockets more or less persistant. Also socket keep alive could be specified to avoid firewall cut connexions without activity. - AJP/1.3 reuse Apache headers decoding to avoid duplicate works in both Apache 2 and Tomcat, these headers are sent binary serialized. - AJP/1.4 (AJP/1.3 successor), add negociation support : - Apache and tomcat could be used in a secure mode, ie they should share the same secret word. - Possible add-on is to provide compression and/or crypt of datas between Apache and Tomcat. - AJP/1.4 should add a 'service layer' which should be used to warn about topology update. Why is it worth the development time of apache volunteers? Well development is allready here, we only need to extract all AJP stuff in a separate library (discussed in tomcat-dev). And why is AJP so advantageous over HTTP/1.1 that we should redesign existing modules to use it? The initial invitation was Apache 2.x module expert advices to design at the best the jk/jk2 possible successor. We didn't ask any httpd member to work on it (even if there is some people involved in tomcat-dev/jk/jk2 allready involved in APR and Apache 2, ie Jean-Frederic Clere). I do apologize but I am not really familiar with the inner workings of tomcat as no webhost I have worked for to date has really pushed it. I think the answers to these questions would be useful for all of us who are more-or-less pure apache users/devs... Yes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebappClassLoader.getURLs Bug!
Shapira, Yoav wrote: Hi, Unfortunately, now that I've moved to Tomcat 5, I discover that the bug is still quite present. There is now a nice getURI() method along with the previous getURL() method. Unfortunately, getURLs() does not use getURI( file ).toURL() or any such as it would need to for the RMI runtime's sake (as it calls getURLs()). The getURI method returns a URL object, not a URI object, as the latter is JDK 1.4-only and we still officially support building and running on JDK 1.3. I agree: you really should be complaining about Sun (who wrote the bad URL handling in the first place). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Costin Manolache wrote: Well, the mod_proxy + enhancements for sticky session + enhancements for passing auth info sounds reasonable - and if nobody wants the JMX support, then maybe we won't need to write a new connector anyway :-) Remy will be happy - we'll only use the http connector. I think AJP has advantages, but if the HTTPd folks only accept a simple solution based on mod_proxy, then so be it, it'll be our entry level connector. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Henri Gomez wrote: It's now time to refactor and redesign it with Apache 2.x (APR/AP) in mind to follow Apache 2.x admins habbits and try to make something simpler. We came on httpd-dev for advice from experts, and may be an extended mod_proxy could be the solution. But we also want to keep the AJP/1.3 and AJP/1.4 protocols since it works well and so a pure HTTP proxy is only part of the game. I think any module that speaks ajp/1.X should be called mod_ajp, keeps things simple and clean. We agree and I wonder if a mod_ajp could be used in conjunction with mod_proxy ? A sort of alternative way to route requests to tomcat. - Could mod_proxy be open to support AJP/1.x as tomcat connections ? I don't think mod_proxy should support ajp, rather a dedicated ajp module should. We agree. But I'm still not convinced a separate protocol is needed when HTTP exists and is supported already. The httpd serves the static content feature can be implemented through extending ProxyPass to support regular expressions, for example: ProxyPass /myWebapp/*.jsp http://tomcat/myWebapp/ I'm not sure if persistent connections over and above HTTP/1.1 keepalives is that useful. Well let see my suggestion : ProxyPass /myWebapp/*.jsp ajp://myajpworker/ myajpworker is not a machine but a virtual resource which could be : - a physical Tomcat using its AJP/1.3 connector - a cluster of physical Tomcats using their AJP/1.3 connector And via AJP/1.4 we could make Apache 2 learn about cluster updates in real-time. Could we have this kind of Virtual Forward service used with mod_proxy ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebappClassLoader.getURLs Bug!
Shapira, Yoav wrote: Hi, Unfortunately, now that I've moved to Tomcat 5, I discover that the bug is still quite present. There is now a nice getURI() method along with the previous getURL() method. Unfortunately, getURLs() does not use getURI( file ).toURL() or any such as it would need to for the RMI runtime's sake (as it calls getURLs()). The getURI method returns a URL object, not a URI object, as the latter is JDK 1.4-only and we still officially support building and running on JDK 1.3. So getURI is essentially doing a file.toURI().toURL() anyway? If so, can we just switch getURLs() to call getURI() rather than getURL()? Or should we switch getURL() to call getURI after attempting to get the canonical file object (which is all it does apart from toURL(), whose results are broken as far as the RMI runtime is concerned)? If need be, I can keep either of these patches in my own distribution, but I always like to see a single, consistent fix for everyone. -- Jess Holle
Re: WebappClassLoader.getURLs Bug!
Remy Maucherat wrote: Shapira, Yoav wrote: Hi, Unfortunately, now that I've moved to Tomcat 5, I discover that the bug is still quite present. There is now a nice getURI() method along with the previous getURL() method. Unfortunately, getURLs() does not use getURI( file ).toURL() or any such as it would need to for the RMI runtime's sake (as it calls getURLs()). The getURI method returns a URL object, not a URI object, as the latter is JDK 1.4-only and we still officially support building and running on JDK 1.3. I agree: you really should be complaining about Sun (who wrote the bad URL handling in the first place). Agreed -- but that won't fix the issue. So can we fix it in 5.0.x or not? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote: Costin Manolache wrote: Well, the mod_proxy + enhancements for sticky session + enhancements for passing auth info sounds reasonable - and if nobody wants the JMX support, then maybe we won't need to write a new connector anyway :-) Remy will be happy - we'll only use the http connector. I think AJP has advantages, but if the HTTPd folks only accept a simple solution based on mod_proxy, then so be it, it'll be our entry level connector. The discussion is still open :) BTW, we could imagine that even AJP/1.4 topology update could came from HTTP/1.1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote: Costin Manolache wrote: Well, the mod_proxy + enhancements for sticky session + enhancements for passing auth info sounds reasonable - and if nobody wants the JMX support, then maybe we won't need to write a new connector anyway :-) Remy will be happy - we'll only use the http connector. I think AJP has advantages, but if the HTTPd folks only accept a simple solution based on mod_proxy, then so be it, it'll be our entry level connector. One issue here: When Apache and Tomcat are used together via AJP13: 1. The host, port, protocol, etc, are exactly that at the Apache level, i.e. one's web app sees Apache and Tomcat as 1 entity. This is a very good thing overall compared to reverse proxying (if that's the mod_proxy proposal). 2. The body content, query string, etc, are reported to one's web application precisely as sent, whereas Tomcat pre-processes them a bit more than picky, low-level request parsing code can accept. [Yes, the picky code is *too* picky, but it isn't mine :-)] -- Jess Holle
Re: Invitation to HTTPD commiters in tomcat-dev
Costin Manolache wrote: Graham Leggett wrote: In all my deployments of tomcat I have never seen the point of a custom protocol that did exactly what HTTP does, so all my tomcat deployments are all HTTP, with a simple mod_proxy frontend. Even the get Apache to server static content feature wasn't enough of a drawcard, as proper HTTP cache handling and a suitable cache solved this problem. It was far more important for me to arrange the web application as a self contained unit - I would rather be more tidy with an install at the expense of a slightly higher load, than sacrifice a clean install to save some cycles. There is a bit more - we want to be able to have Apache authenticate and pass this info to tomcat for example. I don't know if this can be done with mod_proxy ( maybe have it add an extra header - but that may have security problems ). That is a hard requirement for us as well. And in fine, we like to have some JMX like functionnalities in Apache 2, in our case MX for C Management Extension, a way to update Apache 2.x configuration while the server is running... This is possibly a whole separate project in itself. Agreed. It sounds like a great project, but a *separate* project and module. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Henri Gomez wrote: It's now time to refactor and redesign it with Apache 2.x (APR/AP) in mind to follow Apache 2.x admins habbits and try to make something simpler. We came on httpd-dev for advice from experts, and may be an extended mod_proxy could be the solution. But we also want to keep the AJP/1.3 and AJP/1.4 protocols since it works well and so a pure HTTP proxy is only part of the game. I think any module that speaks ajp/1.X should be called mod_ajp, keeps things simple and clean. - Could mod_proxy be open to support AJP/1.x as tomcat connections ? I don't think mod_proxy should support ajp, rather a dedicated ajp module should. But I'm still not convinced a separate protocol is needed when HTTP exists and is supported already. The httpd serves the static content feature can be implemented through extending ProxyPass to support regular expressions, for example: That would be a hard requirement for our usage as well. A huge reason for using Apache is to serve the static content at that level. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Wayne Frazee wrote: Please pardon me for attempting to marshall the obvious however what is the advantage of AJP/1.x over HTTP? - Persistant connections, mod_jk use a pool of socket connections to avoid reopening connections between Apache and Tomcats. You could set socket timeout to make these sockets more or less persistant. Also socket keep alive could be specified to avoid firewall cut connexions without activity. The keep alive stuff turns out to be a hard requirement for many deployments. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
I agree here, it is an excelent idea. If we want to keep it to a minimum - no multi-protocol, no jmx, no multiple servers - then making enhancements to mod_proxy and using http is much better than a mod_ajp. Tomcat httpd is fast enough, and all mod_proxy enhancements for load balancing could be used for more than tomcat. Costin Remy Maucherat wrote: I think using mod_proxy is acceptable for our most important needs, as the Tomcat HTTP/1.1 connnector has acceptable performance. We would need: - JSESSIONID stickiness - persistent connections support - (and of course) load balancing (with a static worker list) with failover - bonus points for auto retry (if the request allows it) to another node when recieving a 503 status SSL client-cert support (which I have no idea how to implement with mod_proxy, or maybe I missed something) and more generally, support for doing auth on the native webserver doesn't seem to be there, which is a problem. For ease of use, we need this Tomcat policy (actually, it's not Tomcat specific, obviously) to be included in the Apache source distribution, and ready to enable. I would like a more custom solution better, but if that's the only acceptable solution for you (and you accept the module into the Apache ;) ), then I'm ok with it. In this case, we would need another, more complex connector for the advanced use cases, but we would have addressed the needs of the majority of users. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote: I think AJP has advantages, but if the HTTPd folks only accept a simple solution based on mod_proxy, then so be it, it'll be our entry level connector. We'll certainly be interested in features like load balancing, sticky sessions, stuff like that - but the general design philosophy is that the functionality should be general enough to be used as widely as possible. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Time for JkMountExclude in jk 1.2.x ?
Have you looked at using JkAutoAlias ? On Tue, Jul 13, 2004 at 12:27:41PM +0200, Henri Gomez wrote: Hi to all, As many I'm puzzled in jk 1.2.x in some case : VirtualHost *:80 ServerName test101.mysys DocumentRoot /www/sys101/htdocs JkMount /* test-101 /VirtualHost VirtualHost *:80 ServerName test102.mysys DocumentRoot /www/sys102/htdocs JkMount /* test-102 /VirtualHost No imagine I want to have /home in test102.mysys mapped no more to tomcat but to local directory. VirtualHost *:80 ServerName test102.mysys DocumentRoot /www/sys102/htdocs JkMount /* test-102 Alias /home/ /www/sys102/home/ Directory /www/sys102/home Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all /Directory /VirtualHost There is no way to get http://test102.mysys/home goes to /www/sys102/home local directory. What about adding support for JkMountExclude : VirtualHost *:80 ServerName test102.mysys DocumentRoot /www/sys102/htdocs JkMount /* test-102 JkMountExclude /home/* Alias /home/ /www/sys102/home/ Directory /www/sys102/home Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all /Directory /VirtualHost These will prevent JkMount to forward /home/* to tomcat worker test-102. Thanks to comments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
although I'm not a commiter, I like to add 2 cents to the discussion. I like the idea of supporting JMX and the capbility of deploying a webapp without restarting the server. From the discussions so far, the task isn't simple, and may not fit the majority of users. if 80% of the users don't have this need, justifying the extra features and possibly added complexity is debatable. Would it be sufficient to create a hook for more advanced mods? There are people using tomcat's admin tool to deploy/redeploy webapps, so having the feature in mod_proxy or whatever would make the edge cases less painful. using JMX would make managing a cluster of servers easier and reduce the need to login to every single server to stop, edit conf files, and restart. peter On Tue, 20 Jul 2004 08:18:39 -0700, Costin Manolache [EMAIL PROTECTED] wrote: Well, the mod_proxy + enhancements for sticky session + enhancements for passing auth info sounds reasonable - and if nobody wants the JMX support, then maybe we won't need to write a new connector anyway :-) Remy will be happy - we'll only use the http connector. Costin Graham Leggett wrote: Henri Gomez wrote: jk was designed a long time ago so may be mod_proxy allready support persistant connections. Persistence will happen on the backend on the condition there was persistence on the frontend. Generally the networks between backend and frontend are fast enough that connection setup is not a problem - a bigger problem is having expensive backend processes hanging around attached to a persistent connection that is not being used (assuming these connections are held by a tomcat thread of course, which may or may not be the case, not sure how tomcat is built internally). Great. And if you handle in the proxy_loadbalancing.c the JSESSION_ID, (sticky session) to map next requests to the tomcat who set it, you'll have everything needed. Sticky sessions has been on my list of things to support for ages - perhaps a proxy_sticky.c module could take a single parameter (the name of the parameter and/or cookie) and keep track of which server served it. If you had redundant frontends you might have a mechanism to keep track of which server is handling which session stored in a shared mechanism. A separate module might keep track of which tomcat servers are up or down, removing a server from the list of available servers on certain events (connection refused, error 4xx, 5xx, whatever). Well LDAP could be use for configuration outside a file. JMX/CMX goes a bit farther since it let you update some characteristics at runtime. But I agree that providing a JMX/CMX facade to Apache 2.x modules will be a good starting point. Costin will certainly clarify this point with you. In fine the discussed mod_ajp module should detect topology change in a second phase to learn for example that a tomcat in a cluster started/stopped a web application, so next requests could be redirected to another tomcat in the cluster. Also you should be able to update the load factor for each tomcat, may be having a load factor by Webapplication. In theory this kind of thing should not be limited to tomcat only, but to web applications (whether PHP, whatever) in general. Perhaps a mechanism that allows the backend to connect to the frontend and say status has changed, I am offering webapp XXX now, so count me into the pool. Or a mechanism for the frontend to poll the characteristics of the backend so that it can autolearn what webapp can be found where (has the advantage of not requiring a special backend module, apart from a magic URL on the backend giving relevant the information) This opens up some interesting possiblities for virtual mappings. Something like this: ProxyPass /myWebapp virtual://myWebbapp (or something) Where proxy can hand out the request to a backend that has recently said hi proxy, I serve myWebapp, feel free to contact me to fulfil a request. Regards, Graham -- - 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]
[Fwd: Re: Invitation to HTTPD commiters in tomcat-dev]
---BeginMessage--- Manni Wood wrote: One of the things I thought AJP did that HTTP proxying to Tomcat could not (but correct me here if I'm wrong) is let the servelt container know whether or not the connection is HTTP vs. HTTPS. This sort of information needs to get passed back to the servlet container to satisfy the servlet specification. This can be easily implemented by a combination of mod_proxy/mod_dir/mod_ssl and a well defined set of request headers - this doesn't justify a whole separate protocol though. It looks like the stuff that ajp can do over and above HTTP can be implemented using HTTP without much trouble. Also, servlets (by the specification) need to be able to manipulate HTP request headers, particularly where cookies are concerned. I was under the impression that AJP allowed this, whereas mod_proxy did not, but perhaps I am wrong? mod_proxy just passes headers (excluding hop by hop headers) between httpd and the backend tomcat, I don't know of any reason why such headers can't be manipulated by a servlet container. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Jess Holle wrote: One issue here: When Apache and Tomcat are used together via AJP13: 1. The host, port, protocol, etc, are exactly that at the Apache level, i.e. one's web app sees Apache and Tomcat as 1 entity. This is a very good thing overall compared to reverse proxying (if that's the mod_proxy proposal). I have no idea how to get around that ;) This seems a showstopper: the user will have to read the connector's documentation. 2. The body content, query string, etc, are reported to one's web application precisely as sent, whereas Tomcat pre-processes them a bit more than picky, low-level request parsing code can accept. [Yes, the picky code is *too* picky, but it isn't mine :-)] I have no idea what your webapp is doing, but it's not portable. All the trasformations done respect the HTTP and servlet specifications. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote: Costin Manolache wrote: Well, the mod_proxy + enhancements for sticky session + enhancements for passing auth info sounds reasonable - and if nobody wants the JMX support, then maybe we won't need to write a new connector anyway :-) Remy will be happy - we'll only use the http connector. I think AJP has advantages, but if the HTTPd folks only accept a simple solution based on mod_proxy, then so be it, it'll be our entry level connector. AJP is an RPC protocol - the binary encoding of http headers doesn't buy us too much ( with coyote httpd ). Session stickiness is easy to add to mod_proxy, and I assume passing auth info is also possible. If we only want to use ajp for forwarding - no back channel for config - then there is no point in using RPC and binary protocol. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Well let see my suggestion : ProxyPass /myWebapp/*.jsp ajp://myajpworker/ myajpworker is not a machine but a virtual resource which could be : - a physical Tomcat using its AJP/1.3 connector - a cluster of physical Tomcats using their AJP/1.3 connector And via AJP/1.4 we could make Apache 2 learn about cluster updates in real-time. Could we have this kind of Virtual Forward service used with mod_proxy ? It's quite possible yes - currently mod_proxy has proxy_http and proxy_ftp to speak HTTP and FTP to the backend, it would make sense to put in proxy_ajp which could speak AJP to the backend, and would have the advantage of following the same config directives as the rest of proxy. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Time for JkMountExclude in jk 1.2.x ?
Glenn Nielsen wrote: Have you looked at using JkAutoAlias ? What do you means ? JkAutoAlias automatically detected Alias/Directory and excluded them from JkMount * ? On Tue, Jul 13, 2004 at 12:27:41PM +0200, Henri Gomez wrote: Hi to all, As many I'm puzzled in jk 1.2.x in some case : VirtualHost *:80 ServerName test101.mysys DocumentRoot /www/sys101/htdocs JkMount /* test-101 /VirtualHost VirtualHost *:80 ServerName test102.mysys DocumentRoot /www/sys102/htdocs JkMount /* test-102 /VirtualHost No imagine I want to have /home in test102.mysys mapped no more to tomcat but to local directory. VirtualHost *:80 ServerName test102.mysys DocumentRoot /www/sys102/htdocs JkMount /* test-102 Alias /home/ /www/sys102/home/ Directory /www/sys102/home Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all /Directory /VirtualHost There is no way to get http://test102.mysys/home goes to /www/sys102/home local directory. What about adding support for JkMountExclude : VirtualHost *:80 ServerName test102.mysys DocumentRoot /www/sys102/htdocs JkMount /* test-102 JkMountExclude /home/* Alias /home/ /www/sys102/home/ Directory /www/sys102/home Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all /Directory /VirtualHost These will prevent JkMount to forward /home/* to tomcat worker test-102. Thanks to comments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - 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: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Graham Leggett wrote: Henri Gomez wrote: It's now time to refactor and redesign it with Apache 2.x (APR/AP) in mind to follow Apache 2.x admins habbits and try to make something simpler. We came on httpd-dev for advice from experts, and may be an extended mod_proxy could be the solution. But we also want to keep the AJP/1.3 and AJP/1.4 protocols since it works well and so a pure HTTP proxy is only part of the game. I think any module that speaks ajp/1.X should be called mod_ajp, keeps things simple and clean. We agree and I wonder if a mod_ajp could be used in conjunction with mod_proxy ? A sort of alternative way to route requests to tomcat. Or maybe just a channel for passing config data ( but leave request passing to mod_proxy ) ? I.e. the only thing that will remain in mod_ajp will be the autoconf and monitoring. - Could mod_proxy be open to support AJP/1.x as tomcat connections ? I don't think mod_proxy should support ajp, rather a dedicated ajp module should. We agree. But I'm still not convinced a separate protocol is needed when HTTP exists and is supported already. The httpd serves the static content feature can be implemented through extending ProxyPass to support regular expressions, for example: ProxyPass /myWebapp/*.jsp http://tomcat/myWebapp/ I'm not sure if persistent connections over and above HTTP/1.1 keepalives is that useful. Well let see my suggestion : ProxyPass /myWebapp/*.jsp ajp://myajpworker/ myajpworker is not a machine but a virtual resource which could be : - a physical Tomcat using its AJP/1.3 connector - a cluster of physical Tomcats using their AJP/1.3 connector Can we simplify this ? Let's drop the word worker too :-) The request is passed to a servlet container that may consist of one or multiple instances. Costin And via AJP/1.4 we could make Apache 2 learn about cluster updates in real-time. Could we have this kind of Virtual Forward service used with mod_proxy ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebappClassLoader.getURLs Bug!
Jess Holle wrote: Agreed -- but that won't fix the issue. So can we fix it in 5.0.x or not? Possibly, but it's risky. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Colm MacCarthaigh wrote:
On Tue, Jul 20, 2004 at 05:20:53PM +0200, Graham Leggett wrote:
The httpd serves the static content feature can be implemented through
extending ProxyPass to support regular expressions, for example:
ProxyPass /myWebapp/*.jsp http://tomcat/myWebapp/
RewriteCond %{REQUEST_URI} ^/(.*)\.jsp$
RewriteRule (.*)http://127.0.0.1:8080$1 [P,L]
RewriteCond %{REQUEST_URI} ^/(.*)/servlet/(.*)$
RewriteRule (.*)http://127.0.0.1:8080$1 [P,L]
.. is what I have, no need for new features :)
Well I didn't see where is load-balancing and fault-tolerance here ?)
That's one of the major feature of jk/jk2 and why many companies
used jk as frontal to Tomcat cluster farms.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Henri Gomez wrote: Well let see my suggestion : ProxyPass /myWebapp/*.jsp ajp://myajpworker/ myajpworker is not a machine but a virtual resource which could be : - a physical Tomcat using its AJP/1.3 connector - a cluster of physical Tomcats using their AJP/1.3 connector And via AJP/1.4 we could make Apache 2 learn about cluster updates in real-time. Could we have this kind of Virtual Forward service used with mod_proxy ? It's quite possible yes - currently mod_proxy has proxy_http and proxy_ftp to speak HTTP and FTP to the backend, it would make sense to put in proxy_ajp which could speak AJP to the backend, and would have the advantage of following the same config directives as the rest of proxy. Well : - mod_proxy + proxy_ajp could be one solution. Now what about the mod_proxy load-balancing add-on ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Costin Manolache wrote: Henri Gomez wrote: Graham Leggett wrote: Henri Gomez wrote: It's now time to refactor and redesign it with Apache 2.x (APR/AP) in mind to follow Apache 2.x admins habbits and try to make something simpler. We came on httpd-dev for advice from experts, and may be an extended mod_proxy could be the solution. But we also want to keep the AJP/1.3 and AJP/1.4 protocols since it works well and so a pure HTTP proxy is only part of the game. I think any module that speaks ajp/1.X should be called mod_ajp, keeps things simple and clean. We agree and I wonder if a mod_ajp could be used in conjunction with mod_proxy ? A sort of alternative way to route requests to tomcat. Or maybe just a channel for passing config data ( but leave request passing to mod_proxy ) ? I.e. the only thing that will remain in mod_ajp will be the autoconf and monitoring. - Could mod_proxy be open to support AJP/1.x as tomcat connections ? I don't think mod_proxy should support ajp, rather a dedicated ajp module should. We agree. But I'm still not convinced a separate protocol is needed when HTTP exists and is supported already. The httpd serves the static content feature can be implemented through extending ProxyPass to support regular expressions, for example: ProxyPass /myWebapp/*.jsp http://tomcat/myWebapp/ I'm not sure if persistent connections over and above HTTP/1.1 keepalives is that useful. Well let see my suggestion : ProxyPass /myWebapp/*.jsp ajp://myajpworker/ myajpworker is not a machine but a virtual resource which could be : - a physical Tomcat using its AJP/1.3 connector - a cluster of physical Tomcats using their AJP/1.3 connector Can we simplify this ? Let's drop the word worker too :-) The request is passed to a servlet container that may consist of one or multiple instances. Agreed, remove the old terms. The proposal about mod_proxy + proxy_ajp could be something fine isn't it. And proxy_ajp could map to a dynamically updated ajp resource ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Manni Wood wrote: I asked you to develop your argument ;) Ah. I'm trying my best. :-) May be you could take a look as documentalist ?) I would very happily volunteer my time to document this new module. Where do I sign up? How do I gain acceptance as a documentor, and if I am accepted, what would my next steps be? I'd love to help. Well what about writing jk 1.2.x but following Apache 2.0 xml documentation. You could start by merging Apache 2.0 directive, like JkMount : http://jakarta.apache.org/tomcat/connectors-doc/jk2/jk/aphowto.html and workers.properties : http://jakarta.apache.org/tomcat/connectors-doc/jk2/jk/workershowto.html Thanks to join us at tomcat-dev :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Can we simplify this ? Let's drop the word worker too :-) The request is passed to a servlet container that may consist of one or multiple instances. Agreed, remove the old terms. The proposal about mod_proxy + proxy_ajp could be something fine isn't it. And proxy_ajp could map to a dynamically updated ajp resource ? Well, we could drop ajp as well from proxy-related config. The important thing is to have the proxy know about a cluster - and provide hooks to allow this to be dynamically configured. mod_ajp would deal only with the cluster ( and other ? ) configuration. Security and extra info about request will be encoded in special headers ( and of course, something should filter those headers from the internet to prevent security issues ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: Invitation to HTTPD commiters in tomcat-dev]
---BeginMessage--- Henri Gomez wrote: - mod_proxy + proxy_ajp could be one solution. Now what about the mod_proxy load-balancing add-on ? Would be a completely separate module. The way proxy works, is that it: - obtains the IP address to connect to (currently via DNS round robin, but a module proxy_loadbalancer might make a more intelligent choice of IP address) - opens a connection to that address (unless a connection is already open due to keepalive behaviour, in which case just use that) - pass control to the backend protocol handler (proxy_http, or proxy_ftp, or proxy_ajp) Load balancing would happen at step one. Such a module would need a way to decide load (in the simplest case, by spreading load, in a more complex case, by actually asking the backend servers for the loads so to make a more intelligent decision). Such a module need not work with tomcat only, but with any backend, and any protocol. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: - mod_proxy + proxy_ajp could be one solution. Now what about the mod_proxy load-balancing add-on ? Would be a completely separate module. The way proxy works, is that it: - obtains the IP address to connect to (currently via DNS round robin, but a module proxy_loadbalancer might make a more intelligent choice of IP address) - opens a connection to that address (unless a connection is already open due to keepalive behaviour, in which case just use that) - pass control to the backend protocol handler (proxy_http, or proxy_ftp, or proxy_ajp) Load balancing would happen at step one. Such a module would need a way to decide load (in the simplest case, by spreading load, in a more complex case, by actually asking the backend servers for the loads so to make a more intelligent decision). Such a module need not work with tomcat only, but with any backend, and any protocol. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote: Jess Holle wrote: One issue here: When Apache and Tomcat are used together via AJP13: 1. The host, port, protocol, etc, are exactly that at the Apache level, i.e. one's web app sees Apache and Tomcat as 1 entity. This is a very good thing overall compared to reverse proxying (if that's the mod_proxy proposal). I have no idea how to get around that ;) This seems a showstopper: the user will have to read the connector's documentation. Certainly things function in a reverse proxy environment and so the more complex situation is handled. The issue is that individual developers *can* do bad things by assuming that the request protocol is that they should use in base tags, etc. Overall, that would just be life, though and is insufficient reason not to leverage mod_proxy. 2. The body content, query string, etc, are reported to one's web application precisely as sent, whereas Tomcat pre-processes them a bit more than picky, low-level request parsing code can accept. [Yes, the picky code is *too* picky, but it isn't mine :-)] I have no idea what your webapp is doing, but it's not portable. All the trasformations done respect the HTTP and servlet specifications. Actually it is rather portable and does not break any spec to the best of my knowledge. It just assumes it can get at the original content body stream, request string, etc, as an alternative to getParameter() without missing anything. Why this is the case is a long story. I also miss forget exactly where things fall down, but Apache, iPlanet (with embedded servlet engine), and IIS (with Tomcat) all work (except config issues with IIS 6...) This appears to be far removed from most folks' experience, so I guess Tomcat's httpd is good enough for most. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebappClassLoader.getURLs Bug!
Remy Maucherat wrote: Jess Holle wrote: Agreed -- but that won't fix the issue. So can we fix it in 5.0.x or not? Possibly, but it's risky. So you'd recommend that I just patch my own distribution, then? [Changing getURL() to convert to a URI first worked fine in 4.1.24...] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: WebappClassLoader.getURLs Bug!
Hi, And wait for a 5.1 release, which may not be long in the making. Yoav Shapira Millennium Research Informatics -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 12:40 PM To: Tomcat Developers List Subject: Re: WebappClassLoader.getURLs Bug! Remy Maucherat wrote: Jess Holle wrote: Agreed -- but that won't fix the issue. So can we fix it in 5.0.x or not? Possibly, but it's risky. So you'd recommend that I just patch my own distribution, then? [Changing getURL() to convert to a URI first worked fine in 4.1.24...] -- Jess Holle - 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: WebappClassLoader.getURLs Bug!
Okay, I'll just change getURL() to be identical to getURI() and all should be well for me. Shapira, Yoav wrote: Hi, And wait for a 5.1 release, which may not be long in the making. Yoav Shapira Millennium Research Informatics -Original Message- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 12:40 PM To: Tomcat Developers List Subject: Re: WebappClassLoader.getURLs Bug! Remy Maucherat wrote: Jess Holle wrote: Agreed -- but that won't fix the issue. So can we fix it in 5.0.x or not? Possibly, but it's risky. So you'd recommend that I just patch my own distribution, then? [Changing getURL() to convert to a URI first worked fine in 4.1.24...] -- Jess Holle - 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 13983] - RMI call from Web Application throws SocketException if CATALINA_HOME has a space in it
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=13983.
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=13983
RMI call from Web Application throws SocketException if CATALINA_HOME has a space in it
--- Additional Comments From [EMAIL PROTECTED] 2004-07-20 17:29 ---
Just a note:
Even though Tomcat 5.0.x's WebappClassLoader has a nice getURI() method, it does
not use it to from its getURLs() method. This means the bug still exists in
Tomcat 5.0.x.
The Tomcat team seems loathe to rock the boat to address this, which is
*somewhat* understandable.
At this point I only care about use case this working in Java 2 v1.4 and higher
and about not destroying any other functionality under Java 2 v1.3.x via a fix
(e.g. by using a 1.4-specific class directly).
For these constraints the fix in Tomcat 5.0.27 can be as simple as:
protected URL getURL(File file)
throws MalformedURLException
{
return jdkCompat.getURI(file); // same implementation as getURI()
}
or one could just call getURI(), but I chose to limit calls to getURI() to those
explicitly looking for a URI rather than a well-formed URL.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Now what about the mod_proxy load-balancing add-on ? The thing I'm most happy about with the simple load balancing + sticky session + failover is that the development would be short (hopefully), be bundled with Apache quickly, and could really help people's experience with Tomcat :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
TAKE ME OFF THIS MAILING LIST IMMEDIATELY... I DID NOT REQUEST THIS AND I DO NOT WANT ANOTHER EMAIL FROM JAKARTA.APACHE.ORG Graham Leggett [EMAIL PROTECTED] wrote: Henri Gomez wrote: jk was designed a long time ago so may be mod_proxy allready support persistant connections. Persistence will happen on the backend on the condition there was persistence on the frontend. Generally the networks between backend and frontend are fast enough that connection setup is not a problem - a bigger problem is having expensive backend processes hanging around attached to a persistent connection that is not being used (assuming these connections are held by a tomcat thread of course, which may or may not be the case, not sure how tomcat is built internally). Great. And if you handle in the proxy_loadbalancing.c the JSESSION_ID, (sticky session) to map next requests to the tomcat who set it, you'll have everything needed. Sticky sessions has been on my list of things to support for ages - perhaps a proxy_sticky.c module could take a single parameter (the name of the parameter and/or cookie) and keep track of which server served it. If you had redundant frontends you might have a mechanism to keep track of which server is handling which session stored in a shared mechanism. A separate module might keep track of which tomcat servers are up or down, removing a server from the list of available servers on certain events (connection refused, error 4xx, 5xx, whatever). Well LDAP could be use for configuration outside a file. JMX/CMX goes a bit farther since it let you update some characteristics at runtime. But I agree that providing a JMX/CMX facade to Apache 2.x modules will be a good starting point. Costin will certainly clarify this point with you. In fine the discussed mod_ajp module should detect topology change in a second phase to learn for example that a tomcat in a cluster started/stopped a web application, so next requests could be redirected to another tomcat in the cluster. Also you should be able to update the load factor for each tomcat, may be having a load factor by Webapplication. In theory this kind of thing should not be limited to tomcat only, but to web applications (whether PHP, whatever) in general. Perhaps a mechanism that allows the backend to connect to the frontend and say status has changed, I am offering webapp XXX now, so count me into the pool. Or a mechanism for the frontend to poll the characteristics of the backend so that it can autolearn what webapp can be found where (has the advantage of not requiring a special backend module, apart from a magic URL on the backend giving relevant the information) This opens up some interesting possiblities for virtual mappings. Something like this: ProxyPass /myWebapp virtual://myWebbapp (or something) Where proxy can hand out the request to a backend that has recently said hi proxy, I serve myWebapp, feel free to contact me to fulfil a request. Regards, Graham -- ATTACHMENT part 2 application/x-pkcs7-signature name=smime.p7s - Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign!
Re: Invitation to HTTPD commiters in tomcat-dev
Colm MacCarthaigh wrote: Using OPTIONS has the advantage of being backwards compatible, if you send OPTIONS to a plain-old HTTP receiver, the standard ACK can be taken to mean yep, I'm here. Intelligent backends (read: modify tomcat and co slightly) can have an X-header or whatever to go I'm accepting this, this and this, and my current load is this. This makes sense - you would just need to tell proxy the possible servers, and an intelligent load balancer might try find out the current status of those servers based on querying options to find out on a regular basis. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: mod_jk 1.2.6 release ? - session tracking cookie
I was thinking something like attached. - Original Message - From: Sandy McArthur [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 7:04 AM Subject: Re: mod_jk 1.2.6 release ? - session tracking cookie On Jul 20, 2004, at 5:27 AM, Henri Gomez wrote: Could you send us you workers.properties ? attached. If you feel like putting more work into this, adding 'fprintf(stderr,...)' statements should go to the Apache error_log. Where did you want me put fprint ? Let us know where you want them and we'll test that code too. Sandy McArthur 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 30217] New: - ROOT.war does not correctly unpack if contains context.xml with a path= attribute
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=30217. 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=30217 ROOT.war does not correctly unpack if contains context.xml with a path= attribute Summary: ROOT.war does not correctly unpack if contains context.xml with a path= attribute Product: Tomcat 5 Version: 5.0.25 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] ROOT.war does not correctly unpack if it contains a META-INF\context.xml with a path= attribute set in the Context element. The context.xml gets correctly copied to the conf\Catalina\localhost directly and named as ROOT.xml, but the war file is not unpacked and the application is not deployed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30218] New: - Jk2 strips terminating '--' from multipart mime encoded form submits
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=30218. 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=30218 Jk2 strips terminating '--' from multipart mime encoded form submits Summary: Jk2 strips terminating '--' from multipart mime encoded form submits Product: Tomcat 5 Version: 5.0.25 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Native:JK AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Jk2 appears to not pass on terminating '--' from multipart mime encoded form submits to the java application, although all data fields are correctly passed on. This can cause file uploads from mixed content forms to fail for example that would work when connecting through server:8080 directly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.6 release ? - session tracking cookie
I see that attachments are still getting stripped from the list :).
The problem is yet-another-typo. The check for a comma cookie-delimiter
ends up re-setting the returned cookie value to NULL, so the lb thinks that
no cookie was sent. If this attachment comes through, it's the patch for
it. I'll commit it later (PST), if nobody else wants it.
- Original Message -
From: Bill Barker [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Tuesday, July 20, 2004 11:35 AM
Subject: Re: mod_jk 1.2.6 release ? - session tracking cookie
I was thinking something like attached.
- Original Message -
From: Sandy McArthur [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Tuesday, July 20, 2004 7:04 AM
Subject: Re: mod_jk 1.2.6 release ? - session tracking cookie
On Jul 20, 2004, at 5:27 AM, Henri Gomez wrote:
Could you send us you workers.properties ?
attached.
--
--
If
you feel like putting more work into this, adding
'fprintf(stderr,...)'
statements should go to the Apache error_log.
Where did you want me put fprint ?
Let us know where you want them and we'll test that code too.
Sandy McArthur
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]
*** jk_lb_worker.cvsTue Jul 20 11:02:38 2004
--- jk_lb_worker.c Tue Jul 20 12:09:57 2004
***
*** 139,145
if((id_end = strchr(id_start, ';')) != NULL) {
*id_end = '\0';
}
! if((id_start = strchr(id_start, ',')) != NULL) {
*id_end = '\0';
}
return id_start;
--- 139,145
if((id_end = strchr(id_start, ';')) != NULL) {
*id_end = '\0';
}
! if((id_end = strchr(id_start, ',')) != NULL) {
*id_end = '\0';
}
return id_start;
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: WebappClassLoader.getURLs Bug!
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 8:28 AM Subject: Re: WebappClassLoader.getURLs Bug! Shapira, Yoav wrote: Hi, Unfortunately, now that I've moved to Tomcat 5, I discover that the bug is still quite present. There is now a nice getURI() method along with the previous getURL() method. Unfortunately, getURLs() does not use getURI( file ).toURL() or any such as it would need to for the RMI runtime's sake (as it calls getURLs()). The getURI method returns a URL object, not a URI object, as the latter is JDK 1.4-only and we still officially support building and running on JDK 1.3. I agree: you really should be complaining about Sun (who wrote the bad URL handling in the first place). I agree that Sun's implementation is brain-dead (who thought that space-separated list of URLs was A Good Idea? :). I looked at WACL the last time I got bit by this, but then decided that it was easier to move the app to a directory w/o spaces than to encode the URLs (e.g. s/ /%20/). 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]
DO NOT REPLY [Bug 30221] New: - AccessControlException (Access denied) thrown when I try to restart my webapp
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=30221. 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=30221 AccessControlException (Access denied) thrown when I try to restart my webapp Summary: AccessControlException (Access denied) thrown when I try to restart my webapp Product: Tomcat 5 Version: 5.0.25 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When I try to restart my webapp using Manager's Stop/Start or Reload, I get several stack traces similar to the one listed below. The stack traces are in the Tomcat window but not in the log file. The issue is not a show-stopper, but it makes it impossible to restart my application. Jul 20, 2004 1:47:43 PM org.apache.catalina.core.StandardContext registerJMX INFO: Error registering wrapper with jmx StandardEngine[Catalina].StandardHost [localhost].StandardContext[/salem] Catalina:j2eeType=WebModule,name=//localhost/s alem,J2EEApplication=none,J2EEServer=none java.security.AccessControlException: Access denied (mx4j.server.MBeanTrustPermission register): MBean class org.apach e.commons.modeler.BaseModelMBean is not trusted for registration java.security.AccessControlException: Access denied (mx4j.server.MBeanTrustPermission register): MBean class org.apache.commons.modeler.BaseModelMBean is not trusted for registration at mx4j.server.interceptor.SecurityMBeanServerInterceptor.checkTrustRegistration (SecurityMBeanServerInterceptor.java:156) at mx4j.server.interceptor.SecurityMBeanServerInterceptor.registration (SecurityMBeanServerInterceptor.java:116) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.registration (DefaultMBeanServerInterceptor.java:113) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.registration (DefaultMBeanServerInterceptor.java:113) at mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.registration (ContextClassLoaderMBeanServerInterceptor.java:108) at mx4j.server.MBeanServerImpl.registerImpl(MBeanServerImpl.java:1051) at mx4j.server.MBeanServerImpl.registerMBeanImpl (MBeanServerImpl.java:1002) at mx4j.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:978) at org.apache.commons.modeler.Registry.registerComponent (Registry.java:871) at org.apache.catalina.core.StandardContext.registerJMX (StandardContext.java:5339) at org.apache.catalina.core.StandardContext.start (StandardContext.java:4357) at org.apache.catalina.core.StandardContext.reload (StandardContext.java:3021) at org.apache.catalina.manager.ManagerServlet.reload (ManagerServlet.java:1014) at org.apache.catalina.manager.ManagerServlet.doGet (ManagerServlet.java:330) at javax.servlet.http.HttpServlet.service(HttpServlet.java:697) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) 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.security.SecurityUtil$1.run (SecurityUtil.java:241) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:500) at org.apache.catalina.security.SecurityUtil.execute (SecurityUtil.java:268) at org.apache.catalina.security.SecurityUtil.doAsPrivilege (SecurityUtil.java:157) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:231) at org.apache.catalina.core.ApplicationFilterChain.access$000 (ApplicationFilterChain.java:50) at org.apache.catalina.core.ApplicationFilterChain$1.run (ApplicationFilterChain.java:140) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:136) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal (StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:152) at
Re: mod_jk 1.2.6 release ? - session tracking cookie
Bill, Much thanks! We've tested the fixed get_cookie back-ported to mod_jk 1.2.5 and it works well. We'll deploy that version into production tonight but I don't expect any problems. I'll let y'all know if there is. Sandy On Jul 20, 2004, at 3:17 PM, Bill Barker wrote: I see that attachments are still getting stripped from the list :). The problem is yet-another-typo. The check for a comma cookie-delimiter ends up re-setting the returned cookie value to NULL, so the lb thinks that no cookie was sent. If this attachment comes through, it's the patch for it. I'll commit it later (PST), if nobody else wants it. smime.p7s Description: S/MIME cryptographic signature
DO NOT REPLY [Bug 30218] - Jk2 strips terminating '--' from multipart mime encoded form submits
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=30218. 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=30218 Jk2 strips terminating '--' from multipart mime encoded form submits --- Additional Comments From [EMAIL PROTECTED] 2004-07-20 20:31 --- I should say that this relates to JK2 running with IIS, I havn't actually tried with the apache version. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30155] - Problem with viewing mail session
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=30155. 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=30155 Problem with viewing mail session --- Additional Comments From [EMAIL PROTECTED] 2004-07-20 20:51 --- I actually removed the configuration regarding the mail session both in web.xml and context.xml. here goes the web.xml, context.xml and server.xml: web.xml: web-app !-- Omit other config -- resource-ref descriptionDB Connection/description res-ref-namejdbc/dsapp1/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth /resource-ref !--resource-ref-- !--descriptionmail/description-- !--res-ref-namemail/Session_send/res-ref-name-- !--res-typejavax.mail.Session/res-type-- !--res-authContainer/res-auth-- !--/resource-ref-- !-- The tomcat role -- security-role descriptionDefault Role for All Users/description role-nametomcat/role-name /security-role /web-app context.xml: Context path=/dsapp1 docBase=dsapp1 debug=99 reloadable=true Logger className=org.apache.catalina.logger.FileLogger prefix=dsapp1_log. suffix=.txt timestamp=true/ !-- NOTE: If you want to use a DataSourceRealm, the Resource must be a global resource -- Realm className=org.apache.catalina.realm.JDBCRealm debug=99 driverName=com.mysql.jdbc.Driver connectionURL=jdbc:mysql://localhost/dsapp1?autoReconnect=trueamp;useUnicode=trueamp;characterEncoding=UTF-8 connectionName=test connectionPassword=test userTable=app_user userNameCol=username userCredCol=password userRoleTable=user_role roleNameCol=role_name / Resource name=jdbc/dsapp1 auth=Container type=javax.sql.DataSource/ ResourceParams name=jdbc/dsapp1 parameter namefactory/name valueorg.apache.commons.dbcp.BasicDataSourceFactory/value /parameter !-- Maximum number of dB connections in pool. Make sure you configure your mysqld max_connections large enough to handle all of your db connections. Set to 0 for no limit. -- parameter namemaxActive/name value100/value /parameter !-- Omit other config -- /ResourceParams !-- This is not working -- !--Resource name=mail/Session auth=Container type=javax.mail.Session/-- !--ResourceParams name=mail/Session-- !--parameter-- !--namemail.smtp.host/name-- !--valuelocalhost/value-- !--/parameter-- !--/ResourceParams-- /Context server.xml: ?xml version='1.0' encoding='utf-8'? Server Listener className=org.apache.catalina.mbeans.ServerLifecycleListener/ Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener/ GlobalNamingResources Environment name=simpleValue type=java.lang.Integer value=30/ Resource auth=Container description=User database that can be updated and saved name=UserDatabase type=org.apache.catalina.UserDatabase/ Resource name=mail/Session_send type=javax.mail.Session/ ResourceParams name=UserDatabase parameter namefactory/name valueorg.apache.catalina.users.MemoryUserDatabaseFactory/value /parameter parameter namepathname/name valueconf/tomcat-users.xml/value /parameter /ResourceParams ResourceParams name=mail/Session_send parameter namemail.smtp.host/name valuesmtp.host.net/value /parameter /ResourceParams /GlobalNamingResources Service name=Catalina Connector acceptCount=100 connectionTimeout=2 disableUploadTimeout=true port=8080 redirectPort=8443 /Connector Connector port=8009 protocol=AJP/1.3 protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler redirectPort=8443 /Connector Engine defaultHost=localhost name=Catalina Host appBase=webapps name=localhost Logger className=org.apache.catalina.logger.FileLogger prefix=localhost_log. suffix=.txt timestamp=true/ /Host Logger className=org.apache.catalina.logger.FileLogger prefix=catalina_log. suffix=.txt timestamp=true/ Realm className=org.apache.catalina.realm.UserDatabaseRealm/ /Engine /Service /Server thanks for your time bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24019] - Unable to compile Class in JSP
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=24019. 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=24019 Unable to compile Class in JSP [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-07-20 21:05 --- The original complain was the message No Java compiler was found to compile the generated source for the JSP. was bogus, but that was not what you got here. What you have here is a javac error, which may and may not be correct; but I have no way of telling without a test case. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] JK and load-balanced POSTs
Attached is a patch against JK 1.2.5 to fix handling of POSTs for
load-balanced workers.
The problem it addresses occurs when an endpoint fails while mod_jk is
trying to send it a POST request. When mod_jk gives up and attempts to
use a different endpoint, the body of the POST is lost. Since the POST is
not part of the new endpoint's state, mod_jk tries to re-read the data
from the client, but the client has nothing more to say, so the read
returns zero bytes. This empty post is sent on to the application server,
confusing it.
The patch fixes this problem by attaching the POST data to the request
state (of type jk_ws_service_t) instead of the endpoint state (of type
ajp_endpoint_t).
Feedback is welcome.
- JoelIndex: jk/native/common/jk_ajp_common.c
===
--- jk/native/common/jk_ajp_common.c(revision 930)
+++ jk/native/common/jk_ajp_common.c(revision 931)
@@ -966,9 +966,9 @@
jk_log(l, JK_LOG_DEBUG,
ajp_send_request 2:
request body to send %d - request body to resend %d\n,
- ae-left_bytes_to_send, jk_b_get_len(op-reply) - AJP_HEADER_LEN);
+ ae-left_bytes_to_send, jk_b_get_len(op-post) - AJP_HEADER_LEN);
-/*
+/* XXX: this comment looks outdated:
* POST recovery job is done here.
* It's not very fine to have posted data in reply but that's the only easy
* way to do that for now. Sharing the reply is really a bad solution but
@@ -1217,9 +1217,18 @@
jk_b_set_buffer_size(op-reply, DEF_BUFFER_SZ);
jk_b_reset(op-reply);
-op-post = jk_b_new((p-pool));
-jk_b_set_buffer_size(op-post, DEF_BUFFER_SZ);
-jk_b_reset(op-post);
+ if (s-post == NULL) {
+ s-post = jk_b_new(s-pool);
+ if (s-post == NULL) {
+ jk_log(l, JK_LOG_ERROR, ERROR: unable to allocate POST buffer);
+*is_recoverable_error = JK_FALSE;
+return JK_FALSE;
+ }
+ jk_b_set_buffer_size(s-post, DEF_BUFFER_SZ);
+ jk_b_reset(s-post);
+ }
+
+ op-post = s-post;
op-recoverable = JK_TRUE;
op-uploadfd = -1; /* not yet used, later ;) */
Index: jk/native/common/jk_service.h
===
--- jk/native/common/jk_service.h (revision 930)
+++ jk/native/common/jk_service.h (revision 931)
@@ -72,6 +72,7 @@
#include jk_map.h
#include jk_global.h
#include jk_logger.h
+#include jk_msg_buff.h
#include jk_pool.h
#include jk_uri_worker_map.h
@@ -235,8 +236,14 @@
a version that doesn't support secret - don't set the secret,
and it'll work.
*/
-char*secret;
+char*secret;
+
/*
+ * The body of the POST, if any.
+ */
+jk_msg_buf_t *post;
+
+/*
* Callbacks into the web server. For each, the first argument is
* essentially a 'this' pointer. All return JK_TRUE on success
* and JK_FALSE on failure.
Index: jk/native/common/jk_util.c
===
--- jk/native/common/jk_util.c (revision 930)
+++ jk/native/common/jk_util.c (revision 931)
@@ -926,4 +926,5 @@
s-attributes_values= NULL;
s-num_attributes = 0;
s-jvm_route= NULL;
+s-post = NULL;
}
Index: jk/native/common/jk_msg_buff.h
===
--- jk/native/common/jk_msg_buff.h (revision 930)
+++ jk/native/common/jk_msg_buff.h (revision 931)
@@ -65,6 +65,7 @@
#ifndef JK_MSG_BUF_H
#define JK_MSG_BUF_H
+#include jk_pool.h
#ifdef __cplusplus
extern C {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30192] - FORM based login Error forwarding to login page
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=30192. 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=30192 FORM based login Error forwarding to login page --- Additional Comments From [EMAIL PROTECTED] 2004-07-20 21:52 --- Problem found: form-login-config was missing from the login-config Should Tomcat have caught this? Remy, I'm not trying to get cross with you but your comment came across as insulting. I am new to J2EE development and no I did not download the Tomcat source code. Instead I investigated as much as I could find (google searchs, mailing list archive, posting on mailing list, etc.) before I posted a possible bug here. Thank you, -D - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jari Auvinen/Kytola is out of the office.
I will be out of the office starting 10.07.2004 and will not return until 09.08.2004. Please, send your urgent enquiries to [EMAIL PROTECTED] Thank you. Best regards Jari Auvinen Kytola Oy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30192] - FORM based login Error forwarding to login page
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=30192. 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=30192 FORM based login Error forwarding to login page [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-07-20 22:02 --- Filing an issue should be a last resort move (otherwise, it's wasted time for everyone, so I'm never happy about it). I expect you would have quickly looked in the source, this is an obvious move to me when I get a NPE (and generally any exception which doesn't seem wrapped). Did you enable XML validation for your test ? By default, validation is disabled, so there can be mandatory elements missing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
IGNACIO SANZ DE LA SERNA está ausente de la oficina.
Estaré ausente de la oficina desde el 14/07/2004 y no volveré hasta el 27/07/2004. Responderé a su mensaje cuando regrese. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
GUILLERMO GONZALEZ AREVALO está ausente de la oficina.
Estaré ausente de la oficina desde el 19/07/2004 y no volveré hasta el 09/08/2004. Responderé a su mensaje cuando regrese. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JUAN CARLOS ROMERO GALLEGO está ausente de la oficina.
Estaré ausente de la oficina desde el 16/07/2004 y no volveré hasta el 13/08/2004. Por favor, envíe su mensaje a José Bravo ([EMAIL PROTECTED]). Please send your message to Mr. José Bravo ([EMAIL PROTECTED]). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_lb_worker.c
billbarker2004/07/20 19:18:46
Modified:jk/native/common jk_lb_worker.c
Log:
Fix nasty typo that was killing the cookie.
Reported By: Sandy McArthur [EMAIL PROTECTED]
Revision ChangesPath
1.22 +2 -2 jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c
Index: jk_lb_worker.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- jk_lb_worker.c20 Jul 2004 14:56:40 - 1.21
+++ jk_lb_worker.c21 Jul 2004 02:18:46 - 1.22
@@ -139,7 +139,7 @@
if((id_end = strchr(id_start, ';')) != NULL) {
*id_end = '\0';
}
-if((id_start = strchr(id_start, ',')) != NULL) {
+if((id_end = strchr(id_start, ',')) != NULL) {
*id_end = '\0';
}
return id_start;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: port number at runtime
request.getServerPort() -Thanks, but this returns the port number of the current request port. But my problem is, say the request is for http: and I want to redirect to https:/.../somefile.jsp. - then ? Basically what is required is a method that will return the port number set in the conf/server.xml file. -Saugata --- Günter_Knauf [EMAIL PROTECTED] wrote: Hi, It will be very usefull if the port number on which the SSL and Http non-ssl ports are running, is available runtime. (Ex:- 8080 and 8443). Is it possible? The int getPort() method of the CoyoteConnector class returns the port number but its not accessible at runtime. If there is a sendRedirect() method in some jsp, where one wants to redirect from http to say https, then the port number must be known in advance. So there is a need for such an API. request.getServerPort() see the jsp snoop example. Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: port number at runtime
Having this as a requirement makes an awful lot of assumptions about the architecture of the container, none of which are helpful in the larger scale. For example, what if you have 2 (or 50) http connectors and the same for https ? And then what about ajp13 ? Or mod_caucho's protocol (I think it's called hessian) ? The reason this is not in the servlet api spec is because it would create more problems than it would solve. There are some cases where you just need to know what your deployment environment is going to be ... this is one of them. Rick saugata ghosh wrote: request.getServerPort() -Thanks, but this returns the port number of the current request port. But my problem is, say the request is for http: and I want to redirect to https:/.../somefile.jsp. - then ? Basically what is required is a method that will return the port number set in the conf/server.xml file. -Saugata -- Servlet v2.4 container in a single 140KB jar file ? Try Winstone (http://winstone.sourceforge.net) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28875] - Multi-byte characters in default error page aren't printed out correctly.
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=28875. 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=28875 Multi-byte characters in default error page aren't printed out correctly. --- Additional Comments From [EMAIL PROTECTED] 2004-07-21 04:31 --- Created an attachment (id=12178) The re-written patch to fix this problem in ErrorReportValve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: port number at runtime
Thanks. Completely agreed with the arguments for not having the API. Right now we put the port numbers in our own projects property file also, apart from server.xml. May be thats the way to do it. -Saugata --- Rick Knowles [EMAIL PROTECTED] wrote: Having this as a requirement makes an awful lot of assumptions about the architecture of the container, none of which are helpful in the larger scale. For example, what if you have 2 (or 50) http connectors and the same for https ? And then what about ajp13 ? Or mod_caucho's protocol (I think it's called hessian) ? The reason this is not in the servlet api spec is because it would create more problems than it would solve. There are some cases where you just need to know what your deployment environment is going to be ... this is one of them. Rick saugata ghosh wrote: request.getServerPort() -Thanks, but this returns the port number of the current request port. But my problem is, say the request is for http: and I want to redirect to https:/.../somefile.jsp. - then ? Basically what is required is a method that will return the port number set in the conf/server.xml file. -Saugata -- Servlet v2.4 container in a single 140KB jar file ? Try Winstone (http://winstone.sourceforge.net) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30225] New: - resource-ref not properly parsed
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=30225. 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=30225 resource-ref not properly parsed Summary: resource-ref not properly parsed Product: Tomcat 4 Version: 4.1.30 Platform: PC OS/Version: Windows XP Status: NEW Severity: Blocker Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When a corresponding resource is not defined in a server.xml, the following web.xml segment: web-app resource-ref res-ref-namejdbc/test/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth /resource-ref ... /web-app Generates the following SAX parser error: Jul 20, 2004 9:58:55 PM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on port 8080 Starting service Tomcat-Standalone Apache Tomcat/4.1.30 Jul 20, 2004 9:58:57 PM org.apache.commons.digester.Digester error SEVERE: Parse Error at line 72 column 11: The content of element type web-app must match (icon?,display- name?,description?,distributable?,context-param*,filter*,filter- mapping*,listener*,servlet*,servlet-mapping*,session-config?,mime- mapping*,welcome-file-list?,error-page*,taglib*,resource-env-ref*,resource- ref*,security-constraint*,login-config?,security-role*,env-entry*,ejb-ref*,ejb- local-ref*). org.xml.sax.SAXParseException: The content of element type web- app must match (icon?,display-name?,description?,distributable?,context- param*,filter*,filter-mapping*,listener*,servlet*,servlet-mapping*,session- config?,mime-mapping*,welcome-file-list?,error-page*,taglib*,resource-env- ref*,resource-ref*,security-constraint*,login-config?,security-role*,env- entry*,ejb-ref*,ejb-local-ref*). at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.endElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown Source) at ... This is a blocker for the following use case: You create a .war containing a servlet which first attempts to locate a DataSource. If a DataSource is not found (null returned), then the servlet uses a jdbc URL, username, and password specified via servlet init parameters to attempt a default DriverManager connection. Because the parse fails on the last line (the /web- app element), all the init parameters are read as null -- that is, opening via a default jdbc URL also fails. This bug makes it virtually impossible to create a commercial .war that can run on any app server. Instead one has to eliminate the resource-ref, have the customer unpack the .war and edit the web.xml with appropriate URL, etc. for their computer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
