Re: [VOTE] Release Plan for Apache Tomcat 4.1
On Wed, 24 Apr 2002, Glenn Nielsen wrote: There are a few additional items I would like to see added. 1. Port my recent mod_jk/apache1.3 new features to mod_jk/Apache2.0 and to jk2 as costin requested. This makes those connectors for use with Apache more consistent. mod_jk2 has lower priority - there is no chance it'll be 'release quality' in this time frame. I do hope to have it ready for a beta, but for 4.1 ( and 4.0.x, 3.3.x ) mod_jk1 remains the server connector. coyote-Jk2 is stable as a Ajp13/Socket connector - i.e. all that matter for mod_jk1. The Unix socket and all advanced features of jk2/java will not be 'release quality' either ( but with a bit of luck and some help from Nacho and maybe others we can have them working and beta-level). I also think the release schedule is too aggressive. I would like to hold off on a beta 1 until May 10, beta 2 May 24, RC 1 June 3. We could switch the numbering scheme to follow the 'original' idea - numbered milestones. Like Apache 2 is doing. Instead of beta1, RC1, etc - we'll just use 4.1.0, 4.1.1, etc - with the 'release quality' happening when everyone is happy. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PROPOSAL] New version numbering scheme
On Wed, 24 Apr 2002, Ignacio J. Ortega wrote: De: Remy Maucherat [mailto:[EMAIL PROTECTED]] Enviado el: miércoles 24 de abril de 2002 23:41 Which will be the rules to advance the build numbers? Probably every time the release manager feels the code is stable and better than the previous build. I'm +1 on the proposal, with the mention that the 'label' should be attached _after_ one week or so - i.e. after the milestone is tested. Each milestone should work and pass some basic tests. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [JK2] Some questions
First - Nacho, my next commit ( probably tommorow, after I check
everything ) will be large, please commit whatever you have changed
and I'll resolve the conflicts.
The biggest change is using JK_OK / JK_ERR consistently for return
types and using java style
rc=function()
if( rc != JK_OK )
...
instead of the
if( function() ) {
}
The second change is some cleanup in the dispatch() and jk_handle,
so JNI/SHM will use the same mechanism and code.
Now answers:
isapi_redirector2.dll has started to load and log this night :) and is
giving me a beautiful NPE when trying the ajp13 connector from tc33,
it's suppoused to work, ?
Is it a NPE or a core dump ? I got it working with Apache + 3.3, 4.0,
4.1 ( ajp13-socket, unix, jni ), but I only did basic tests.
Send me the trace, I'll take a look.
i have some caveats about the way the default logger logs by default ;),
the code is trying printf to stderr, what can i do? into IIS there is no
stderr to log to by default,
2 choices - either don't do anything until the file is set, or
implement a jk_log_windows.c that sends all messages to the windows
even log.
The second can sit in common/ and be conditionally compiled - in
case someone else wants to use it ( for apache or another server ),
it's not specific to IIS ( but windows ).
( the log should go to whatever IIS or the server is using normally )
i'll need to readd the register keys for default logger file and log
level :(, It seems to me rather messy because i will need to override
and/or ignore those properties setted in the wk2.p file, to, at least,
be consistent and to have only one place to configure log..
If you need to - then add them. That's not the biggest problem and we
can change later.
ANother Caveat is the serverRoot property, there is no serverRoot
available here in CrapLand ;), i've mimic the serverRoot with a registry
value, but it seems to me that the default config values should be more
agnostic..
serverRoot is used to locate the conf/ and logs/ and will be used
to locate webapps/ ( with Glen's fix ).
( I'm not sure - there are 2 servers - probably we should find a way to
keep all logs, confs, files in the same place ).
BTW, many thanks - I can't finish this without your help, is much
harder than I ever expected.
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [JK2] Some questions
On Thu, 25 Apr 2002, Ignacio J. Ortega wrote: keep all logs, confs, files in the same place ). This can work for apache, win32 or *x but for IIS it's really hard, i much prefer to keep all this things near tomcat, not near the System32 directory :), anyway having a totally agnostic way, given the OOP over C style jk2 has, this could be done by making a specialized config ( inheriting from the actual one ) for every server? this specialized config would make the need asumptions for the server using jk2? The set serverRoot to tomcat.home/catalina.base. We need a base directory for all locations. That should be the only setting you need in the registry - the top level dir where we can start seeing conf/, logs/, etc. That's very confusing for apache - we have apache/conf and tomcat/conf, but for IIS it should be easier - you have only one dir :-) Advanced configuration is possible - but we should start with workers2.properties then do 'auto-guessing' ( Glen ) and special settings on the various components. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
1 problem with Coyote
Hi Remy, I would like to add one more method in Coyote - it won't touch existing functionality, just add a way for jk to fingure out what webapps are configured in the server ( I'm trying to update the auto-conf stuff ) Do you mind if I add a new ACTION_WEBAPP hook, with code in the 2 connectors to call this hook for each webapplication ( all existing and every one deployed at runtime ) ? The code changes are not big, and it won't affect the rest of the code. I'm not sure what the 'param' should be - for starters I'll just use a Hashtable with various attributes for the app ( vhost, context path, docbase ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk2 connector
On Sun, 28 Apr 2002, Michael Delamere wrote: -g -O2 -pthread-DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURC E -D_SVID_SOURCE -DAP_HAVE_DESIGNATED_INITIALIZER -I../../include -I/usr/lo I've got it. Sorry, we mostly use ant for development - the Makefile gets updated less often. ( the bug was that we didn't pass the JK_CFLAGS to the compiler - so it didn't know that we do have and use apr and tried to compile the 'transition' layer ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk2
I commited a fix. Let me know if it still fails. BTW, mod_jk2 is not even beta - we are still doing a lot of major changes and some important features are not yet finished. Don't waste your time with jk2 unless you want to contribute to the development ( sending feedback and comments and reviewing the code is an important contribution ) Costin On Sun, 28 Apr 2002, Michael Delamere wrote: Hi, When comparing the 2 files that you suggested I notice the following: There seem to be a number of differences between the 2 files (possibly due to apache2.0.35??) and -prefer-pic doesn´t exist in the rules.mk at all. regards Michael MAKEFILE: ## Based on rules.mk ## ALL_CFLAGS = $(EXTRA_CFLAGS) $(NOTEST_CFLAGS) $(CFLAGS) ALL_CPPFLAGS = $(DEFS) $(EXTRA_CPPFLAGS) $(NOTEST_CPPFLAGS) $(CPPFLAGS) ALL_LDFLAGS = $(EXTRA_LDFLAGS) $(NOTEST_LDFLAGS) $(LDFLAGS) ALL_LIBS = $(EXTRA_LIBS) $(NOTEST_LIBS) $(LIBS) ALL_INCLUDES = $(INCLUDES) $(EXTRA_INCLUDES) # Compile commands COMPILE = $(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(ALL_INCLUDES) SH_COMPILE = $(LIBTOOL) --mode=compile $(COMPILE) -prefer-pic MOD_LINK = $(LIBTOOL) --mode=link $(CC) -module -shared $(LT_LDFLAGS) $(ALL_LDFLAGS) # RULES.MK # Combine all of the flags together in the proper order so that # the user-defined flags can always override the configure ones, if needed. # Note that includes are listed after the flags because -I options have # left-to-right precedence and CPPFLAGS may include user-defined overrides. # ALL_CFLAGS = $(EXTRA_CFLAGS) $(NOTEST_CFLAGS) $(CFLAGS) ALL_CPPFLAGS = $(DEFS) $(EXTRA_CPPFLAGS) $(NOTEST_CPPFLAGS) $(CPPFLAGS) ALL_CXXFLAGS = $(EXTRA_CXXFLAGS) $(NOTEST_CXXFLAGS) $(CXXFLAGS) ALL_LDFLAGS = $(EXTRA_LDFLAGS) $(NOTEST_LDFLAGS) $(LDFLAGS) ALL_LIBS = $(EXTRA_LIBS) $(NOTEST_LIBS) $(LIBS) ALL_INCLUDES = $(INCLUDES) $(EXTRA_INCLUDES) # Compile commands COMPILE = $(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(ALL_INCLUDES) CXX_COMPILE = $(CXX) $(ALL_CXXFLAGS) $(ALL_CPPFLAGS) $(ALL_INCLUDES) SH_COMPILE = $(LIBTOOL) --mode=compile $(COMPILE) -c $ touch $@ SH_CXX_COMPILE = $(LIBTOOL) --mode=compile $(CXX_COMPILE) -c $ touch $@ LT_COMPILE = $(LIBTOOL) --mode=compile $(COMPILE) -c $ touch $@ LT_CXX_COMPILE = $(LIBTOOL) --mode=compile $(CXX_COMPILE) -c $ touch $@ # Link-related commands LINK = $(LIBTOOL) --mode=link $(COMPILE) $(LT_LDFLAGS) $(ALL_LDFLAGS) -o $@ SH_LINK = $(SH_LIBTOOL) --mode=link $(COMPILE) $(LT_LDFLAGS) $(ALL_LDFLAGS) $(SH_LDFLAGS) $(CORE_IMPLIB) $(SH_LIBS) - MOD_LINK = $(LIBTOOL) --mode=link $(COMPILE) -module $(LT_LDFLAGS) $(ALL_LDFLAGS) -o $@ ### - Original Message - From: [EMAIL PROTECTED] To: Michael Delamere [EMAIL PROTECTED] Cc: List Tomcat-Dev [EMAIL PROTECTED] Sent: Sunday, April 28, 2002 3:31 PM Subject: Re: mod_jk2 On Sun, 28 Apr 2002, Michael Delamere wrote: Hi, When I try to run make in jakarta-tomcat-connectors/jk/native2/server/apache2 I get a compile error. One of the errors is: gcc: unrecognized option `-prefer-pic' Does this mean that I´ve got the wrong version of gcc? I´ve got v2.95 installed. Are you on Linux ? The -prefer-pic seems to be supported - I cutpasted it from the Apache's Makefile ( genereated by configure ). You can take a look in APACHE_HOME/build/rules.mk and 'synchronize' this with the jk makefile. ( and let us know what you change :-) In any case - -prefer-pic shouldn't be needed - I'll double check and remove it. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jakarta-tomcat-connectors documentation/summaries
On Sun, 28 Apr 2002, Christopher K. St. John wrote: mod_jserv where to get the source: java-jserv repository I would recommend jakarta-tomcat, the version there has been tested the most with tomcat ( there are no significant changes AFAIK ). unerlying protocol: AJP11 Ajp12 - also supported in mod_jk1. works with: servlet containers: JServ Tomcat3.x as well ( which supports ajp12 ). web servers: old versions of Apache httpd All apache1.3 versions. mod_jk should jk2 be listed out separately? Probably not. why it was written: originally, clean-up of mod_jserv. Refactoring of mod_jserv to better abstract the server and protocol. where to get documentation: jakarta-tomcat-connectors/jk tomcat-dev mailing list archives http://jakarta.apache.org/tomcat/tomcat-3.3-doc/mod_jk-howto.html http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/jk.html http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/jk2.html There are some interesting how-tos on the web ( including for lb and tomcat4 ) - maybe we can do a google search and link. primary developers: evolved from mod_jserv (see above) Gal Shachor, IBM Research, Haifa Lab. refactored mod_jserv many others? Check the sources, there are plenty of names there :-) works with: servlet containers: jserv? Well, yes. tomcat-3 tomcat-4 web servers: domino apache 1.3 apache 2.0? netscape others? AOLServer ( not in the main tree ). it's big thing: production use Also - it's the area/component of tomcat with the largest number of individual commiters ( by my count at least ). And more important - one of the things that 3.x and 4.x share and seem to bring cooperation from both sides. underlying protocol: AJP, see mod_jserv evolution: AJP12, binary AJP13, better SSL support. the current protocol. AJP14, in testing. see comments below. No ajp14 protocol - we agreed to stick with ajp13 as a wire protocol ( i.e. no extensions ). Additional APIs will be added but the marshalling will stay the same. My hope is that the next thing will be a standard protocol. special powers: load balancing with both tomcat 3 and tomcat 4 Prety good OO model, good abstraction for server and protocol, etc. [EMAIL PROTECTED]: It works ( barely :-) with Apache2.x and 1.3. The connector for apache1.3 can be used as a basis for updating IIS/iPlanet. That's for mod_jk2 - and I think Nacho got the IIS done ( or close ). [EMAIL PROTECTED] : What we called ajp14 are a set of new APIs for config, shutdown, MD5 auth - added by Henri. Ajp14 API is not 'released', and the current plan is to postpone it after the first release of jk2 And we should probably find a better name for it to avoid future confusion between protocol and API. webapp web servers: apache 1.3 others? Apache2. I think they got IIS and iPlanet - don't know what level of support. coyote why it was written: ??? Lots of optimizations ( especially in 4.0 ), better abstractions, etc. status: being phased in as default for tomcat 4.1 Will also be the main connector for 3.x ( at least for jk2, but also http/1.1 ) works with: servlet containers: tomcat-3 tomcat-4 web servers: using jk2: apache 1.3 apache 2.0 status? others? Coyote is the architecture for the java side - it supports HTTP/1.1 ( as standalone ) and all servers that jk1 supports. Coyote-jk is using ajp13 - so works with all jk versions. operating systems: ?? java. primary developers: Remy Maucherat [EMAIL PROTECTED] others? Bill Barker. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [NITPICK] didn't see this one coming...
On Sun, 28 Apr 2002, Bill Barker wrote: Deprecating it was never voted, and the mention should be removed from the documentation. IMO, the issue should then be voted upon. Pre-voting: -1 to deprecate WARP. Now that Pier is back, and interested in maintaining it, WARP deserves an equal chance to compete with AJP. The only positive lesson to come out of the Valve vs. Interceptor holy war was that competition is good. I agree. There's nothing wrong with multiple connectors - and 3.3 still supports mod_jserv ( and I know people who use it ). I think we do agree that coyote will be the connector for http and jk, and we'll include any other component that is actively developed and maintained. As long as Pier and JFC are working on webapp, it'll be alive. However I do think we should somehow document better what's happening - many people have the strange impression that webapp is going to replace jk. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [NITPICK] didn't see this one coming...
On Mon, 29 Apr 2002, Remy Maucherat wrote: However I do think we should somehow document better what's happening - many people have the strange impression that webapp is going to replace jk. I'd like to find a way to indicate that the two preferred connectors are: - Coyote HTTP/1.1 - Coyote JK 2 (AJP with mod_jk, JNI) And to clearly indicate that for whatever OS Pier is using and Apache2, users can also use mod_webapp. ( for 3.3 we do the same for mod_jserv and Apache1.3 ). Note that mod_jk2 is not and will not be ready for 4.1, and JNI doesn't work with 4.x in mod_jk1. PROPOSAL: Rename Coyote-jk2 - coyote-jk. Or just drop the coyote-jk and coyote-http from documentations, no need to confuse users. There is the coyote connector, it supports http/1.1 and mod_jk. The current stable release of mod_jk is mod_jk1.5, the alpha/beta release is mod_jk2. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [NITPICK] didn't see this one coming...
On Mon, 29 Apr 2002, Remy Maucherat wrote: Yes, I suppose it's one connector supporting many protocols, so maybe it would be a good idea to do that, call the thing Coyote and merge the two pages (esp since there is little HTTP/1.1 docs needed). Or make one main page with sub-pages. Porbably so - for the java side and server.xml there is no reason to confuse people. There is one connector - that's it. Probably even 'coyote' can be removed from the docs :-) - if we agree ( and so far it seems we do ) that Coyote is going to be the default connector ( and I believe we can get a majority for both 4.0 and 3.3 to support that ) - then it'll be just that, 'the' connector. That doesn't mean the others are not supported - just that we recommend one default. I had a question about the autoconfiguration with JK 2. Is it the same as in JK 1 ? If it's not, a large part of the documentation is stale. Yes, using the same code - I can move the config generator from o.a.ajp - but it's better to let people use the same class names. The autoconfig generates mod_jk1 config ( JkMount, etc ). For mod_jk2 the config is different, and a different autoconf will be used ( I'll send a proposal in the next mail ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [NITPICK] didn't see this one coming...
On Mon, 29 Apr 2002, Pier Fumagalli wrote: As long as we find and fix the docs that sugest that mod_webapp is 'replacing' mod_jk and is the 'default' Apache2 ( or whatever) connector - I'm fine. I heard many people who believe that - and it is certainly not the case. Costin [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Mon, 29 Apr 2002, Remy Maucherat wrote: However I do think we should somehow document better what's happening - many people have the strange impression that webapp is going to replace jk. I'd like to find a way to indicate that the two preferred connectors are: - Coyote HTTP/1.1 - Coyote JK 2 (AJP with mod_jk, JNI) And to clearly indicate that for whatever OS Pier is using and Apache2, users can also use mod_webapp. I can cover for OS/X and Solaris 8 (both X86 and SPARC). That's all I have access to ATM (my flatmate's Linux box is a happily hand-tuned llama slow Debian box, basically impossible to compile whatever on it) J-F uses a couple of whacko ;) systems, and something else (???) Henri is building RPMs for WebApp already, and since it's another dialect of a pseudo POSIX-compliant OS, things should work there as well, and it's pretty easy to provide fixes when he tries to build the thing. I used to have an HP-UX box as well, but the power supply died last week, and the cost to replace that was much more than the value of the box itself, so it just ended up in the bin with my kitty litter last week... I know that Covalent has some HP-UX boxes, if they want to put them on-line, it might be good (since I was hosting HP-UX for the entire Apache community) Apart from that, if someone wants to do some Windows porting, he's more than welcome to volunteer (as you are well-aware of, it's kinda impossible to run MSVC from remote, you _have_ to have a console. The only alternative would be someone providing a Wintel PC with a valid license of MSVC and an SSH server to do builds on, although it might get nasty when you think about doing all those NMAKE files)... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jakarta-tomcat-connectors documentation/summaries
On Mon, 29 Apr 2002, Christopher K. St. John wrote: Ok, I'm maybe being thick here, but I want to make sure I've got this straight. The idea is that anyone who's clueful enough to search the archives is likely to come across the term AJP14, so it's best to give them a hint (even if term isn't going to mean anything to somebody who just wants to evaluate the current set of connectors) So, to confirm: AJP13 defines marshalling protocols. It also has a command set that uses those marshalling protocols. AJP14 uses the same marshalling protocol as AJP13, but extends the command set. The distinction is important, because in the past major version number changes in AJP meant an entirely new binary protocol. AJP14 is for the future, sometime after the release of jk2. It's still being discussed. No. AJP14 was an experiment to extend AJP13 - but we agreed that keeping Ajp13 stable and frozen and stable ( and remaining compatible with the whole range of tomcats ) is better than whatever improvements we could gain. And I strongly believe that in the future we'll either stick with ajp13, or implement a subset of XDR or CDR - i.e. a standard marshalling ( and an even smaller subset of the rpc semantics ). To avoid confusion, we should stop discussing about Ajp14 - and stop using the same term for protocol and API. There is one wire ( binary ) protocol, ajp13. PROPOSAL: let's use 'jk1 API' to refer to the set of methods/callbacks used in jk1 - that's the base API that is supported in all tomcat versions ( starting with 3.2 ). The only reference to ajp14 should point that there is no ajp14. Ajp13 was designed from start as a RPC-like protocol ( with minimal overhead, etc ), and we don't have any use case where ajp13 wouldn't work. The only limitation is that it support only 255 methods ( unless we use an expansion ), since it has a byte as method code ( to facilitate table-based dispatching ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: logrotate and tomcat 3.3/4.0/4.1
On the java side ? I think we should just use commons-logging, and the admin/ or manager/ or some other ( java-based code ) to control the underlying logger ( which should probably default to log4j when somebody has the time to do this ). There is no need to complicate things with -HUP and java - it isn't difficult ( I even started to work on that in the jk jni code ), but it would be much cleaner/portable/etc to just use java mechanisms. ( of course, JMX is a good choice - and log4j does support JMX ) Costin On Mon, 29 Apr 2002, GOMEZ Henri wrote: Hi to all, Did there is plan to help implement logrotate for Tomcat 3.3/4.0/4.1 ? On production the logs could became very important after weeks of use and should be cleanup. The usual way under Unix is to use logrotate which generally send a KILL -HUP/USR1 to the process which in turn close its open logs files, and create new one. The logrotate daemon then do the cleanup, renaming, compression and so on. What's the perspective for tomcat's ? - Use log4j in cycle mode and avoid use of System.out / System.err ? - Team up with jakarta-service to be able to catch up the signal and do what's needed ? Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jakarta-tomcat-connectors documentation/summaries
On Mon, 29 Apr 2002, Pascal Forget wrote: mod_jk and mod_jk2 do not work properly with Apache 2.0. mod_jk works fine with Apache2.0 - at least the CVS HEAD. If someone has the time, we should replace/update the .tar.gz we distribute, that version has a bug that was fixed. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jakarta-tomcat-connectors documentation/summaries
On Mon, 29 Apr 2002, Pascal Forget wrote: mod_jk and mod_jk2 do not work properly with Apache 2.0. And mod_jk2 is not yet supposed to work ( since it's not even alpha ). But it does :-) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.0.4] [VOTE] Beta 3 release
On Mon, 29 Apr 2002, Remy Maucherat wrote: I merged the patches I wanted to merge in the 4.0.x branch. I left out the patch for bug 7575 in the end, as it was a bit riskier. If you think it should be merged anyway, I'll merge it. So here's the release vote, as promised earlier. I'd like to propose releasing 4.0.4 Beta 3, and since the number of changes over 4.0.4 Beta 2 is small, to consider it a release candidate. As a significant number of issues have been fixed since 4.0.2/4.0.3, it would be a good idea to plan to release 4.0.4 Final soon after. ballot [ ] +1 Yes, and I'll help [ ] +0 Yes [ ] -1 No: +0 - I have no time. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
PROPOSAL: mod_jk2 autoconfig
Hi, I spent a lot of time on this - and I think this is a very good solution. Please send feedback - the sooner the better... I think the current solution of generating configs on tomcat startup, or having tomcat send it's config to apache is wrong. Basically what I would like to propose is similar with what Glen implemented in jk1 for apache1.3 ( the webapp/ directory auto-conf )- with few enhancements. The major requirement is that mod_jk2 is configured with the location of the webapp/ directory. Inside webapp, it'll look for directories and configure them automatically, like tomcat is doing. Some 'special' files ( like in 4.1 and the 3.3 apps- files ) will also be read and used to load webapps that sit in different directories. In addition, a separate directory ( named ??? ) can be used with a host-based hierarchy. Given that most users are using a single host and the current webapps/ habbits, the vhost hierarchy will be different from the 'default server'. For each discovered webapp ( either directory or CONTEXT.jk2 file ) , jk will look for WEB-INF/jk2/map.properties and load the file. The map.properties file will be generated from web.xml - using a small tool ( I'll commit the first code shortly ) that is independent of tomcat ( it doesn't require starting tomcat ). It can be used as CLI, as ant task or as a bean inside an admin or deploy application. The tool curently uses DOM - and very simple and strictly specialized code, no LoadModule or anything that is beyond web.xml content. In addition, the tool may generate Apache-specific configuration fragments for the 'native' mapper ( as you may remember, jk2 can map URIs using it's internal mapper - but also using Location and Set-Handler directives ). It'll also generate JkMounts for backward compat. All other code from the jk1 autoconf will be separated ( or replaced with some templates ) - the location of jk, other global settings are better to be done manually ( and have decent defaults ). Finally, the shmem system that is ( will be ) used for autoconfiguration of workers ( i.e. when a tomcat starts up it can add itself automatically, without admin intervention ) can be used by the deploy/admin tool to reconfigure uri mappings ( with the common mapper, the native mapper still requires a soft restart - but that can be automated as well ). Implementation-wise - this is not difficult, and can be done pretty fast if Glenn and few other people step in. I believe that's going to be very close to 'minimal' pain for the regular user while preserving the ability to fine tune everything. NOTE: jk2 will use a different model for the lb, see next mail. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
PROPOSAL: mod_jk2: Group/Instance
One of the major goals of mod_jk2 is simpler configuration. This proposal will cover the 'workers'. 1. The 'worker' name is deprecated. It refers to too many things in mod_jk, and causes too much confusion ( i.e. it is a 'handler', coresponds to a jvmRoute, a protocol, a channel ). 2. We'll use the term 'channel' to define the connections between jk and tomcat. Each channel will follow a standard naming syntax: channel.socket:HOST:PORT channel.unix:/PATH channel.jni:jni Altenatively, the local part can be used as a shortcut. Each channel will use Ajp13 protocol by default ( or whatever is specific to the transport, or overriden ). 3. We'll use the term 'instance' ( XXX or a better name if you can sugest one ) to refer to a single tomcat VM. That's what will be used in the jvmRoute. A tomcat instance can be reached by multiple channels. By default, each instance will have one socket channel and will be named by the local part ( i.e. HOST:port ). That's the name that'll identify the VM. 4. We'll use the term 'group' to reffer to a set of tomcat 'instances' that share a number of applications. The default group will be called 'lb'. One 'instance' can be part of one or many groups. 5. Each URI will be associated with a 'group'. In what used to be: JkMount /examples ajp13 the 'group' will replace ajp13. As I said, the default group is called 'lb' and includes all tomcat instances that are defined. For each application that is installed on all instances, the 'lb' group must be used. If you have a sophisticated setup - and an app is installed only on some instances, you can use names like lb_examples, and explicitely define what tomcat instances belong to the group. 6. The webapps will be defined by a hierarchy of directories ( host/webapp_name ) ( see previous mail ). Each webapp is obviously mapped consistently to one group, which will be defined inside the WEB-INF/jk2/map.properties. 7. Each channel will have an associated 'instance' ( it can't go to 2 tomcats ) and groups. The lb configuration is done automatically based on those attributes. The mappings are done automatically based on the hierarchy. If no map.properties is found, the whole webapp will be forwarded to the default group ( the common case ). I believe this model covers all current use cases. Please, please, send feedback and let me know if you can help ( implementation, documentation, testing ), but feedback is the first step. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.0.4] [VOTE] Beta 3 release
IMPORTANT: please update the mod_jk sources from the HEAD, there is a bug in the apache2 support - the current .tar.gz is broken and that creates a lot of pain. ( Larry - I don't know if 3.3.1 includes the jk from j-t-c, but if it does it would be helpfull to post an updated jk ) Costin On Mon, 29 Apr 2002 [EMAIL PROTECTED] wrote: On Mon, 29 Apr 2002, Remy Maucherat wrote: I merged the patches I wanted to merge in the 4.0.x branch. I left out the patch for bug 7575 in the end, as it was a bit riskier. If you think it should be merged anyway, I'll merge it. So here's the release vote, as promised earlier. I'd like to propose releasing 4.0.4 Beta 3, and since the number of changes over 4.0.4 Beta 2 is small, to consider it a release candidate. As a significant number of issues have been fixed since 4.0.2/4.0.3, it would be a good idea to plan to release 4.0.4 Final soon after. ballot [ ] +1 Yes, and I'll help [ ] +0 Yes [ ] -1 No: +0 - I have no time. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.0.4] [VOTE] Beta 3 release
On Mon, 29 Apr 2002, Remy Maucherat wrote: [ ] +1 Yes, and I'll help [X] +0 Yes [ ] -1 No: /ballot If nobody votes +1, this release will never happen. Not that I would really care, I would get more sleep :-D I think I need one more +1. I can change my vote to +0.5 - I'll try it with jk and do some basic testing. But I have to sleep too. What about postponing it for few days ( or a week ) ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jk2: uriMap changes
Since I got a free day, I did another pass on jk_uriMap. I started by porting Glen's GENERAL_CONTEXT changes, then I added the virtual host ( that is required by IIS ). I also added vhost aliaes. I did some optimizations. And I ended up removing Glen's and all other 'special' mapping rules ( at least temporarily ), and reimplementing the whole alghoritm to match exactly the same way as tomcat. I'll run some basic tests and check in - the code may be broken and a bit unstable for few days, but this will avoid many problems later. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AW: PROPOSAL: mod_jk2 autoconfig
On Tue, 30 Apr 2002, Hans Schmid wrote: I can not see how this works if you have Apache and Tomcat on different machines. This way we do not have a webapp/ directory on that Apache server. It works fine. There are 2 cases: 1. You want Apache to serve static pages. That's the 'normal' case, and it automatically require that you _have_ the webapp (at lest the static pages, you can remove the clasesses, lib, etc ) on the apache server. 2. You don't want apache to serve static pages for the app. In this case you'll just put a small file in the webapp/ ( myApp.jk2 or something similar - see how 3.3 apps-myApp.xml or 4.1 webapps/myApp.xml works ), with the single mapping that is required to forward all requests. Even in the second case, I think it is easier to 'deploy' one conf file per webapp in a clear format than editing workers.properties. Did I misunderstand the intent of this configuration? Is it a 'best guess' for simple setups? Probably in our scenario we have to configure it manually anyways. Manual configuration will work, of course. In tomcat you can still edit server.xml. It's just that I would strongly discourage that for 'normal' use. Some 'special' files ( like in 4.1 and the 3.3 apps- files ) will also be read and used to load webapps that sit in different directories. same here we are on different machines. Again, all you need is to install 1 file on the server machine for each webapp ( without static files ). I personally believe that is a very bad choice to not let apache serve the static files, but it'll work. Just make sure, everything in the config can be overwritten and configures manually if possible in a single file (as workers.properties right now) Either workers2.properties, or one file in the webapps ( named after the application, with .jk2 extension ). The file can be used if you have the docRoot in a different place in the apache server. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: PROPOSAL: mod_jk2: Group/Instance
On Tue, 30 Apr 2002, Bernd Koecke wrote: some weeks ago I send a patch for mod_jk for an only routing lb_worker. A few days later I sent the docu. Henry Gomez said, that it should be commited. But it I think it isn't in the repository. But its the same with me here, to mutch work for to less time :). I think it is in mod_jk, I remember seeing the commit. And I think I commited it in jk2 as well ( after some modifications ). I need sticky sessions but no loadbalancing in the module. If a request without a session comes in, it should be routed to the _local_ tomcat. Well, there is another use-case with the exact same behavior - Apache2 with tomcat in JNI mode. All requests without session should be routed to the _jni_ channel ( i.e. in-process, minimal overhead ). It's exacly the same - so be sure I do my best to handle this case :-) Apache2 acts like a 'natural' load-balancer/fail-over, with the parent process monitoring for crashes and it starts/stop childs based on load. I think this could be possible with the associated instance of a channel (item 7). Then I have to configure all four nodes for the same group. Because all nodes will serve the same webapps and associate the channel with this group. But for this I need a non balancing group. I don't see if the default behavior of a group is balancing and if this can be switched off. Is this right or do I miss something? The default is balancing, but you can tune this using weithgs ( and I think we use your code for making one instance 'top priority'). Please check the code, take a look and send additional comments/patches. It's not yet completely done, of course. Thanks, Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: PROPOSAL: mod_jk2 autoconfig
On Tue, 30 Apr 2002, GOMEZ Henri wrote: I think the current solution of generating configs on tomcat startup, or having tomcat send it's config to apache is wrong. when tomcats and httpd servers run on differents machines you need to have a form of link between them, and that's why I proposed autoconf to be added to ajp13 (I don't tell ajp14 to avoid confusion). I know. However ( see my previous answer on this topic ) we should get apache to serve the static files - for performance, etc - and that would require the webapp to be on the apache machine anyway. And in the case you want one extra round-trip for each static page, it is still possible to install one small file for each app. The 'ctl' or 'status' workers are supposed to do exactly what you say - get status updates 'over the wire' ( but using HTTP - it's not performance critical and easier ) and eventually change and save the new conf ( save is implemented already in jk_config, but not used yet ). I agree we have a sort of chicken and eggs problems here since httpd servers need to know which tomcat are available to try to connect to them to get the configuration. No chicken and egg here if the config is persistent. Similar with how JMX works - you change/add configs at any time during runtime, it saves the config, and next time you have what you configured, without requiring the JMX manager to be up and re-do the config. httpd server should have a thread (or fork in AP 1.3) to listen to incoming broadcast notification and determine if there is a new tomcat in (or out) and contact newcomer to get its config informations. In case of tomcat caming out, it should remove references to the old tomcat. That would be the ctl handler, and the shm will allow each apache instances to get the message. I know there are other, more sophisticated solutions - but I prefer ( at least for the short term ) a plain HTTP and plain config file. Later we can implement 'broadcast' or other advanced solutions ( like using an LDAP server ?) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: PROPOSAL: mod_jk2 autoconfig
On Tue, 30 Apr 2002, Glenn Nielsen wrote: Both generating an apache config file on startup and my mod_jk change which auto mounts context's make the assumption that the Tomcat webapps directory is available to the web server. This may not be the case for instances of Tomcat on a remote system. See my previous mails. The only assumption is that you'll have at least one config file on the apache server ( but in a webapps/ directory instead of a line in workers.properties ). It would be best if information about what contexts are configured, which of the configured contexts are available, and the request URI's to map to Tomcat was pushed from Tomcat to Apache via the network (channel ?). I agree - and I was proposing to use a plain HTTP request to communicate between Tomcat and apache, and shared memory to communicate between apache processors. There would still be a need for JkAutoAlias for those who want apache to server static content for a web app which is available via the fs. Yes, and this whole proposal would still need your help :-) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AW: AW: PROPOSAL: mod_jk2 autoconfig
On Tue, 30 Apr 2002, Hans Schmid wrote: For the few bits of static content in our webapps (few logos) we do not really care (yet). They are served by Tomcat. So we do not even have a Tomcat installed on our webservers - so no webapps directories. You don't have to have tomcat installed - you can have a webapps directory without tomcat :-) My proposal works regardless of tomcat's presence - all you need is a hierarchy of directories and some config files in some pre-set locations - it will resemble ( or be the same with ) tomcat's webapps/. If you have the 'real' webapp installed in the hierarchy ( or the static subset - you can remove all dynamic pages ), then we'll just use the directory name and WEB-INF/jk2/ for configuration. If you don't want any file on the apache server - you just have one file for each webapp with the basic config information. The only issue is making this consistent and easy ( and eventually allow us in future to implement reloading ). We make heavy use of the apps-myall.xml files in TC 3.3.1 - but as I said, no Tomcat on our webservers. We have 2 hardware loadbalanced small pizzaboxes running Apache and three bigger Solaris machines running our Tomcats and the database. I understand. This is just one more simple overhead - instead of editing httpd.conf and use JkMount you'll use one file for each application. Or just ignore this proposal and use manual configuration - what I'm trying to solve is getting 'simple things simple'. Have not yet figured out how to combine our static DocumentRoot plus serving static contents from our webapps. One easy way would be to configure the /webapps location to be the same dir with the DocumentRoot. ( of course, some Deny for WEB-INF will be required - but that's allways the case and we can do it automatically ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [4.1.0] Anyone testing it ?
On Wed, 1 May 2002, GOMEZ Henri wrote: And coyote/http11/jk need tomcat 4 to be built ! I'll have to try some kind of bootstrap action in my rpm, start compiling TC 4.x with binaries, then goes to JTC and rebuild it against newly built TC 4.x, then install these in place of bundled binaries ?(8 I think you can compile coyote without 4.x/3.x ( it has autodetection and will not compile the parts that depend on tomcat ). Then you can compile the rest of jtc, as it depends only on coyote. Then 3.3/4.x, and recompile coyote to get the tomcat specific part. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New committer: Christopher St John
On Wed, 1 May 2002, Remy Maucherat wrote: I'd like to propose Christopher St John cks at distributopia.com as a committer on Tomcat. Christopher has contributed ideas and code to do some improvements to the design of Catalina. More importantly, he seems very motivated and willing to contribute very significant time and effort on Tomcat. He has my +1. +1 Wellcome ! Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: jakarta-tomcat-connectors documentation/summaries
On Thu, 2 May 2002, Ignacio J. Ortega wrote: I can admit all other reasons, but jk never has been unmaintained for any period of time in the past, more, prior to webapp announce, or more or less at the same time, Dan Milstein and Henri did a big work documenting and studiying the sources, the protocol and the api.. and I think I've also been around since jk was written until now. ( I even wrote a lot of the java code, and some pieces of C ) True, I'm not very fast on fixing bugs or documentation - and sometimes I have the same attitude 'works for me' as Pier. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4CoyoteServerSocketFactory.java
On Wed, 1 May 2002, Bill Barker wrote: Add missing public for getFactory. Couldn't access the method through reflection without being public. Revision ChangesPath 1.2 +1 -1 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteSe rverSocketFactory.java I had thought that we had agreed to deprecate this one (in favor of some day being able to get PureTLS working in 4.1.x). Not that I object to Amy's change, but I hate to see her wasting her time on something that is going away. I thought PureTLS was working in 4.1.x ( and coyote ). At least the networking code has all the hooks, there are just few problems with the certs. Is there any additional problem ? ( if we're going to deprecate, it would be good to do it before the release ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AW: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/commonShm.java
On Thu, 2 May 2002, Hans Schmid wrote:
We have two Tomcats in a lb group. Only one is running at a time with
lbfactor=1,
the other has lbfactor=0 assinged but is not running - all requests go to
TC1
When we upgrade our system we update the classes/jars and start the second
Tomcat TC2 in the group,
switch the lbfactor of TC1 to 0 and the lbfactor fo TC2 to 1 and do a
graceful
restart of apache. This way old sessions still go to TC1 whereas new
sessions go to TC2.
That's exactly what I'm trying to do :-)
( almost - if on the same machine, TC1 going up will automatically add it
to the lb group, and eventually if a TC is detected to go down, it'll be
automatically removed )
Costin
After all sessions on TC1 have ended, we shutdown TC1 and TC2 serves
everything.
Next update goes in the oposit direction (start TC1, switch lbfactors, wait
for the end of all
sessions on TC2 and finally shutdown TC2.
Thanks,
Hans
Still to add:
- display ( nicely ) the information in the shm
- read info from shm ( like slots owned by apache processes with
statistics - in a future release )
Revision ChangesPath
1.9 +27 -0
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/Shm.java
Index: Shm.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/S
hm.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- Shm.java 1 May 2002 22:40:17 - 1.8
+++ Shm.java 2 May 2002 03:18:01 - 1.9
@@ -95,6 +95,7 @@
boolean unregister=false;
boolean reset=false;
+String dumpFile=null;
// Will be dynamic ( getMethodId() ) after things are stable
static final int SHM_SET_ATTRIBUTE=0;
@@ -102,6 +103,8 @@
static final int SHM_ATTACH=3;
static final int SHM_DETACH=4;
static final int SHM_RESET=5;
+static final int SHM_DUMP=6;
+static final int SHM_DESTROY=7;
public Shm() {
}
@@ -112,6 +115,13 @@
file=f;
}
+/** Copy the scoreboard in a file for debugging
+ * Will also log a lot of information about what's in the
scoreboard.
+ */
+public void setDump( String dumpFile ) {
+this.dumpFile=dumpFile;
+}
+
/** Size. Used only if the scoreboard is to be created.
*/
public void setSize( int size ) {
@@ -199,6 +209,20 @@
this.invoke( msg, mCtx );
}
+public void dumpScoreboard(String fname) throws IOException {
+if( apr==null ) return;
+MsgContext mCtx=createMsgContext();
+Msg msg=(Msg)mCtx.getMsg(0);
+C2BConverter c2b=(C2BConverter)mCtx.getNote(C2B_NOTE);
+msg.reset();
+
+msg.appendByte( SHM_DUMP );
+
+appendString( msg, fname, c2b);
+
+this.invoke( msg, mCtx );
+}
+
public void setNativeAttribute(String name, String val)
throws IOException {
if( apr==null ) return;
MsgContext mCtx=createMsgContext();
@@ -315,8 +339,11 @@
return;
}
init();
+
if( reset ) {
resetScoreboard();
+} else if( dumpFile!=null ) {
+dumpScoreboard(dumpFile);
} else if( unregister ) {
unRegisterTomcat( host, port );
} else {
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: PROPOSAL: mod_jk2: Group/Instance
On Thu, 2 May 2002, Amund Elstad wrote: (1) all requests without a session are routed to a specific tomcat instance (if that instance is working). That has been added, and it should work in both jk1 and jk2 ( I don't remember who sent the patch, but I remember adding it ). If it doesn't work yet, is easy to fix. This is essential for jk2's JNI worker, which fits perfectly this case ( you don't want to send via TCP when you have a tomcat instance in the same process ). (2) Tomcat instances in standby or soft shutdown mode where they serve requests bound by established sessions, and requests without a session only if all non-standby instances have failed. That's what the SHM scoreboard is going to do ( among other things ). You can register tomcat instances ( which will be added automatically ), or unregister - in which case no new requests ( except the old sessions ) will go to the unregistered tomcat. Costin [EMAIL PROTECTED] wrote: On Tue, 30 Apr 2002, Bernd Koecke wrote: some weeks ago I send a patch for mod_jk for an only routing lb_worker. A few days later I sent the docu. Henry Gomez said, that it should be commited. But it I think it isn't in the repository. But its the same with me here, to mutch work for to less time :). I think it is in mod_jk, I remember seeing the commit. And I think I commited it in jk2 as well ( after some modifications ). I need sticky sessions but no loadbalancing in the module. If a request without a session comes in, it should be routed to the _local_ tomcat. Well, there is another use-case with the exact same behavior - Apache2 with tomcat in JNI mode. All requests without session should be routed to the _jni_ channel ( i.e. in-process, minimal overhead ). It's exacly the same - so be sure I do my best to handle this case :-) Apache2 acts like a 'natural' load-balancer/fail-over, with the parent process monitoring for crashes and it starts/stop childs based on load. I think this could be possible with the associated instance of a channel (item 7). Then I have to configure all four nodes for the same group. Because all nodes will serve the same webapps and associate the channel with this group. But for this I need a non balancing group. I don't see if the default behavior of a group is balancing and if this can be switched off. Is this right or do I miss something? The default is balancing, but you can tune this using weithgs ( and I think we use your code for making one instance 'top priority'). Please check the code, take a look and send additional comments/patches. It's not yet completely done, of course. Thanks, Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: TC41 Test Drop
On Thu, 2 May 2002, Anthony W. Marino wrote: I would like to run TC41 with however I have some questions I need answered. 1) Do I need to (should I) update the coyote connectors available in this drop with a more recent drop found somewhere else? I don't think so. You can wait for the next milestone, or use the nightly if you want. 2) What mod_jk2 drop should I use to test TC41/Apache2 integration? mod_jk1 whould be used - I'm not sure if Remy updated the .tar.gz. Later in the release cycle we'll start populating the binary directories. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: PROPOSAL: mod_jk2: Group/Instance
On Thu, 2 May 2002, Bernd Koecke wrote: misunderstood it. After you said that my patch is included a had a closer look at mod_jk. I can't see anything of my code but I found the special meaning of the zero lb_factor/lb_value. It seems that I didn't understand it right at the first time. This could solve my problem but after a closer look and some testing I found another problem. When you set the lb_value in workers.properties to 1 for the local tomcat and 0 for the others, you get the desired behavior. But if you switch off the local tomcat for a short time you come into trouble. The problem is the 0 for the other workers. The calculation of lb_worker transforms the 0 to _inf_. Because 1/0 for a double is _inf_. This is greater than any I think there is a piece that checks for 0 and sets it to DEFAULT_VALUE (==1 ) before doing 1/lb. While looking at the code - I'm not very sure this whole float is needed, I'll try to find a way to simplify it and use ints ( maybe 0..100 with some 'special' values for NEVER and ALLWAYS, or some additional flags ). But the way it works ( or at least how I understand it ) is that if the main worker fails, then we look at all workers in error state and try the one with the oldest error. And the 'main' worker will be tried again when the timeout expires. I haven't tested this too much, I just applied the patches ( that I understand :-), I'll add some more debugging for this process and maybe we can find a better solution. But this functionality is essential for the JNI worker and very important in general - so I really want to find the best solution. If you have any patch idea, let me know. To avoid further confusion and complexity in the lb-factor/value, I think we should add one more flag ( 'local_worker' ? ) and use it explicitely. Again, patches are wellcome - it's allways good to have different ( and more ) eyes looking at the code. ( that can go in both jk1, but I can't see a release of jk2 without this functionality ) Costin other lb_value and greater than the lb_value of the local tomcat. But after a failure of the local tomcat he is in error_state. After some time its set to recovering and if the local tomcat is back again the function jk(2)_get_max_lb gets the highest lb_value. This is _inf_ from one of the other workers. The addition of a value to _inf_ is meaningless. You end up with an lb_value of _inf_ for the local worker. If this worker isn't the first in the worker list, it will never be choosen again. Because his lb_value will never be less than another lb_value, because all the other workers have _inf_ as theire lb_values. So every request without a session will be routed to the first of the other tomcats. The only way out is a restart of the local apache after tomcat is up and running. But I don't know when tomcat is finished with all his contexts and started the connectors. I didn't looked very deep into jk2, but I found the same get_most_suitable_worker and get_max_lb functions. The jk2_get_max_lb function will always return _inf_. In your answer to some other mails you said, that workers could be removed. Do I understand it right, that if my local tomcat goes down his worker is removed from the list and after he is comming up again added to the worker list with reseted lb_value (only for mod_jk2)? The next days I will look in the docu and code of jk2 and give it a try. May be all my problems gone away with the new module :). Sorry if I ask stupid questions, but I want to make it working for our new cluster. Thanks Bernd This is essential for jk2's JNI worker, which fits perfectly this case ( you don't want to send via TCP when you have a tomcat instance in the same process ). (2) Tomcat instances in standby or soft shutdown mode where they serve requests bound by established sessions, and requests without a session only if all non-standby instances have failed. That's what the SHM scoreboard is going to do ( among other things ). You can register tomcat instances ( which will be added automatically ), or unregister - in which case no new requests ( except the old sessions ) will go to the unregistered tomcat. Costin [EMAIL PROTECTED] wrote: On Tue, 30 Apr 2002, Bernd Koecke wrote: some weeks ago I send a patch for mod_jk for an only routing lb_worker. A few days later I sent the docu. Henry Gomez said, that it should be commited. But it I think it isn't in the repository. But its the same with me here, to mutch work for to less time :). I think it is in mod_jk, I remember seeing the commit. And I think I commited it in jk2 as well ( after some modifications ). I need sticky sessions but no loadbalancing in the module. If a request without a session comes in, it should be routed to the _local_ tomcat. Well, there is another use-case with the exact same
Re: PROPOSAL: mod_jk2: Group/Instance
Hi Bernd, First, many thanks for your help :-) No, I think not :). I checked it yesterday. With some additional log statements in the validate function of jk_lb_worker.c you get the value _inf_ for the lb_factor and lb_value (line 434-444). Because if it would be set to 1, my config hadn't worked. Because I set the local worker to 1 and the others to 0. I'll check again, and fix it if necesarry. I wrote some code in jk2 that seems to solve the problem, and I can backport this to jk1 if it is correct. Probably this is my mistake - I remember the discussion and the patch that was sent for this problem, and most likely I did something wrong commiting it ( i.e. I did few changes trying to simplify it, and it seems I 'simplified' too much ). But my memory still has the patch's logic which seemed fine :-) This is possible, but then you must add a check if the value is 0. Because without it you calc 1/0 with an int and this will give you an error. Yes, of course. 0 will continue to mean 'default worker'. I'm not very comfortable with float calculations in the critical path ( and in an area that is executed concurently !). The only problem is what happens on overflows - the lb_value may become 0 ( or a small value ) and then the worker will take all the load. Thats not the whole story. Its right you will check the main worker when its back again and use it only once. Because when the request was successful handled rec-in_recovering is true (line 332 of jk_lb_worker.c, service function). Than get_max_lb get the value _inf_ from one of the other worker. Than the things happen which I said in my prior mail. That was it what I did in my sent patch, the additional documentation was sent a few days later. But my additions to the lb_worker were a little bit to complex. You are right we should get it when we use the flag only on the main worker and change the behavior after a failure for this worker. But we need the trick with 0/inf for the other worker, because only with this we have the situation that the other worker wouldn't be asked when there is no session and the main worker is up. Ok, can you send the patch again :-) ? For going back to the main worker - if we let it with lb_value=0 at all time ( i.e. we don't alter that at any time ), and only in_error_state is set on failure - then I believe the thing will work fine. I will try to build another patch and send it. I think it could be possible without an additional flag. Great ! Another tought about this: When you use double and we fix the handling after an error, the main worker would never reach _inf_. Because the lb_factor is 1 if lb_value wasn't 0. After choosing the worker this value is added to the lb_value. But with a high value for lb_value the differenc between two savable double numbers is greater than the lb_factor. But this is only interessting in theory. I think in real world we will reboot apache before this will happen :). That may become a problem if we use ints. Costin Bernd ( that can go in both jk1, but I can't see a release of jk2 without this functionality ) Costin other lb_value and greater than the lb_value of the local tomcat. But after a failure of the local tomcat he is in error_state. After some time its set to recovering and if the local tomcat is back again the function jk(2)_get_max_lb gets the highest lb_value. This is _inf_ from one of the other workers. The addition of a value to _inf_ is meaningless. You end up with an lb_value of _inf_ for the local worker. If this worker isn't the first in the worker list, it will never be choosen again. Because his lb_value will never be less than another lb_value, because all the other workers have _inf_ as theire lb_values. So every request without a session will be routed to the first of the other tomcats. The only way out is a restart of the local apache after tomcat is up and running. But I don't know when tomcat is finished with all his contexts and started the connectors. I didn't looked very deep into jk2, but I found the same get_most_suitable_worker and get_max_lb functions. The jk2_get_max_lb function will always return _inf_. In your answer to some other mails you said, that workers could be removed. Do I understand it right, that if my local tomcat goes down his worker is removed from the list and after he is comming up again added to the worker list with reseted lb_value (only for mod_jk2)? The next days I will look in the docu and code of jk2 and give it a try. May be all my problems gone away with the new module :). Sorry if I ask stupid questions, but I want to make it working for our new cluster. Thanks Bernd This is essential for jk2's JNI worker, which fits perfectly this case ( you don't want to send via TCP when you have a tomcat instance in the same process ). (2) Tomcat instances in standby or soft
Re: Admin webapp save-to-XML
Ok, I don't want to start a flame war or anything - but I really don't like the current solution. For short term - we can live with it, and I can accept that as long as we are commited to replace it with something better. I spent a lot of time on this issue - there are many solutions around - Mozilla, gnome, KDE, linuxconf, win32 registry, etc. There one essential requirement: the manager should preserve all elements and config that he doesn't understand. The best solution IMHO is to have a layer between the config file and the configuration. Right now we have XmlMapper ( or however it's called now ) pushing the config info directly into the components, and the components generating config fragments. That will loose information and makes the xml too hardcoded in. In jk we have a jk_config object that reads the properties and sits between config changer and the components. Any change in config ( by wire protocol, shm, etc ) can be registered by jk_config and he can persist it. And it's trivial to later change the format and interface to the config file ( to use LDAP or registry or xml ). A similar thing can be done in java - it is obviously harder with XML, but it can be done. The simplest implementation would be to read the XML as DOM, use the DOM-SAX transformer to get things configured ( while preserving the DOM ), and have the MBeans make calls to the Config object to make the aproriate config changes. This would eventually allow replacing the XML with an LDAP ( which would be nice for clustering and farming ), it would preserve comments and all unmanaged elements, and I believe it would be cleaner and easier. Just MHO. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: PROPOSAL: mod_jk2: Group/Instance
On Fri, 3 May 2002, GOMEZ Henri wrote: 1. The 'worker' name is deprecated. It refers to too many things in mod_jk, and causes too much confusion ( i.e. it is a 'handler', coresponds to a jvmRoute, a protocol, a channel ). +1, worker term should be related to a processing job/thread not communication (a multiplexing worker could handle multiple connections) Actually, I would rather not use it at all. It's too easy to confuse it with a 'worker in a pool' ( i.e. the tomcat instance ), and we used it too much to not create future confusions. - 'group' should be used when mapping requests ( even if the group consist of a single instance ). - 'tomcatId' is the attribute to identify a particular tomcat instance ( and will default for socket channels to host:port, but I still have to push this into coyote's upper layer ) - 'channel' should be used when reffering to a connection method - 'handler' is probably the right term for the actual request processor ( worker_ajp13, worker_status, etc ). By default, each instance will have one socket channel and will be named by the local part ( i.e. HOST:port ). That's the name that'll identify the VM. Only one socket channel listening but with multiple active sockets isn't it ? Sure, but it doesn't makes sense to listen on 2 ajp13 ports ( I think ). In any case, the 'first' ajp13 port will be used to create the host id, and we should assume it's there. ( it's not required by the code, but for our own sanity and to keep things clear. ) 4. We'll use the term 'group' to reffer to a set of tomcat 'instances' that share a number of applications. The default group will be called 'lb'. One 'instance' can be part of one or many groups. Group will group VM (which could be in the same or differents machines) Group is an 'lb'. You can have a group with a single tomcat instance ( i.e. what we had when we did JkMount /foo ajp13 ). And a tomcat instance can belong to multiple groups. In other words, 'groups' are defined by the way webapps are deployed - if you have one or many webapps deployed on certain instances, they'll form the 'group' and all webapps must be mapped to the group. The common case - when all servers run the same apps - you just have the 'default' group and all apps can be mapped to the default 'lb' group. The webserver(s) will receive notification of map.properties, the planned autoconf features of ajp14. Let's call this 'autoconf features of ajp13' :-) Yes, and this can also be done using the shm - it'll be used to send notifications about tomcat instances going up or down, it's easy to extend to notify about additiona webapps. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] added handling of a main worker in jk_lb_worker, Re:PROPOSAL: mod_jk2: Group/Instance
Done. BTW, you may have an older version - you should update from head and then test. Thanks. Costin On Fri, 3 May 2002, Bernd Koecke wrote: Hi Costin, it wasn't difficult, so here is the new patch. The new (old) behavior is: The main worker is defined by a lb_value of 0. This will never be changed in jk_lb_worker. The other workers can get a value greater than 0. If the value from config file is less than 0 it is multiplicated with -1. Your are right this is a better solution. We can switch from doubles to int and we get the other worker balanced if the main worker is down. Bernd Bernd Koecke wrote: Hi Costin, [EMAIL PROTECTED] wrote: Hi Bernd, First, many thanks for your help :-) your welcome, its a lot of fun :) No, I think not :). I checked it yesterday. With some additional log statements in the validate function of jk_lb_worker.c you get the value _inf_ for the lb_factor and lb_value (line 434-444). Because if it would be set to 1, my config hadn't worked. Because I set the local worker to 1 and the others to 0. I'll check again, and fix it if necesarry. I wrote some code in jk2 that seems to solve the problem, and I can backport this to jk1 if it is correct. Probably this is my mistake - I remember the discussion and the patch that was sent for this problem, and most likely I did something wrong commiting it ( i.e. I did few changes trying to simplify it, and it seems I 'simplified' too much ). But my memory still has the patch's logic which seemed fine :-) This is possible, but then you must add a check if the value is 0. Because without it you calc 1/0 with an int and this will give you an error. Yes, of course. 0 will continue to mean 'default worker'. see below I'm not very comfortable with float calculations in the critical path ( and in an area that is executed concurently !). The only problem is what happens on overflows - the lb_value may become 0 ( or a small value ) and then the worker will take all the load. Thats not the whole story. Its right you will check the main worker when its back again and use it only once. Because when the request was successful handled rec-in_recovering is true (line 332 of jk_lb_worker.c, service function). Than get_max_lb get the value _inf_ from one of the other worker. Than the things happen which I said in my prior mail. That was it what I did in my sent patch, the additional documentation was sent a few days later. But my additions to the lb_worker were a little bit to complex. You are right we should get it when we use the flag only on the main worker and change the behavior after a failure for this worker. But we need the trick with 0/inf for the other worker, because only with this we have the situation that the other worker wouldn't be asked when there is no session and the main worker is up. Ok, can you send the patch again :-) ? For going back to the main worker - if we let it with lb_value=0 at all time ( i.e. we don't alter that at any time ), and only in_error_state is set on failure - then I believe the thing will work fine. Thats the invers from the actual situation. So my patch from a few hours earlier this day depends on the fact that the other worker get a lb_value of 0 in the config file. This will be converted to _inf_ and the main worker gets 1 and this will be the minimal lb_value of the balanced workers. If we want the possibility to switch to ints I could send a new patch which handles 0 as a special value for the main worker. Should I? Bernd I will try to build another patch and send it. I think it could be possible without an additional flag. Great ! Another tought about this: When you use double and we fix the handling after an error, the main worker would never reach _inf_. Because the lb_factor is 1 if lb_value wasn't 0. After choosing the worker this value is added to the lb_value. But with a high value for lb_value the differenc between two savable double numbers is greater than the lb_factor. But this is only interessting in theory. I think in real world we will reboot apache before this will happen :). That may become a problem if we use ints. Costin [...] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jk_lb_worker.c patch
Hi Mathias, I think we understand your use case, it is not very uncommon. In fact, as I mentioned few times, it is the 'main' use case for Apache ( multi-process ) when using the JNI worker. In this case Apache acts as a 'natural' load-balancer, with requests going to various processes ( more or less randomly ). As in your case, requests without a session should allways go to the worker that is in the same process. The main reason for using '0' for the local worker is that in jk2 I want to switch from float to int - there is no reason ( AFAIK ) to do all the float computation, even a short int will be enough for the purpose of implementing a round-roubin with weitghs. BTW, one extension I'm trying to make is support for multiple local workers - I'm still thining on how to do that. This will cover the case of few big boxes, each with several tomcat instances ( if you have many G of RAM and many processors, sometimes is better to run more VMs instead of a single large process ) In this case you still want some remote tomcats, for failover, but most load should go to the local workers. For jk2 I already fixed the selection of the 'recovering' worker, after timeout the worker will go through normal selection instead of beeing automatically chosen. For jk1 - I'm waiting for patches :-) I wouldn't do a big change - the current fix seemed like a good one. I agree that changing the meaning of 0 may be confusing ( is it documented ? my workers.properties says it should never be used ). We can fix that by using an additional flag - and not using special values. Another special note - Jk2 will also support 'gracefull shutdown', that means your case ( replacing a webapp ) will be handled in a different way. You should be able to add/remove workers without restarting apache ( and I hope mostly automated ). Let me know what you think - with patches if possible :-) Costin The setup I use is the following, a load balancer (Alteon) is in front of several Apache servers, each hosted on a machine which also hosts a Tomcat. Let's call those Apache servers A1, A2 and A3 and the associated Tomcat servers T1, T2 and T3. I have been using Paul's patch which I modified so the lb_value field of fault tolerant workers would not be changed to a value other than INF. The basic setup is that Ai can talk to all Tj, but for requests not associated with a session, Ti will be used unless it is unavailable. Sessions belonging to Tk will be correctly routed. The load balancing worker definition is different for all three Ai, the lbfactor is set to 0 for workers connecting to Tk for all k != i and set to 1.0 for the worker connecting to Ti. This setup allows to have sticky sessions independently of the Apache handling the request, which is a good thing since the Alteon cannot extract the ';jsessionid=.' part from the URL in a way which allows the dispatching of the requests to the proper Ai (the cookie is dealed with correctly though). This works perfectly except when we roll out a new release of our webapps. In this case it would be ideal to be able to make the load balancer ignore one Apache server, deploy the new version of the webapp on this server, and switch this server back on and the other two off so the service interruption would be as short as possible for the customers. The immediate idea, if Ai/Ti is to be the first server to have the new webapp, is to stop Ti so Ai will not be selected by the load balancer. This does not work, indeed with Paul's patch Ti is the preferred server BUT if Ti fails then another Tk will be selected by Ai, therefore the load balancer will never declare Ai failed (even though we managed to make it behave like this by specifying a test URL which includes a jvmroute to Ti, but this uses lots of slb groups on the alteon) and it will continue to send requests to it. Bernd's patch allows Ai to reject requests if Ti is stopped, the load balancer will therefore quickly declare Ai inactive and will stop send it requests, thus allowing to roll out the new webapp very easily, just set up the new webapp, restart Ti, restart Ai, and as soon as the load balancer sees Ai, shut down the other two Ak, the current sessions will still be routed to the old webapp, and the new sessions will see the new version. When there are no more sessions on the old version, shut down Tk (k != i) and deploy the new webapp. My remark concerning the possible selection of recovering workers prior to the local worker (one with lb_value set to 0) deals with the load balancer not being able in this case to declare Ai inactive. I hope I have been clear enough, and that everybody got the point, if not I'd be glad to explain more thoroughly. Mathias. Paul Frieden wrote: Hello, I'm afraid that I am no longer subscribed to the devel list. I would be happy to add my advice for this issue, but I don't have time to keep up with the entire devel list.
Re: TC4.1 APR Error Logged In Catalina.out
On Sun, 5 May 2002, Anthony W. Marino wrote: SEVERE: APR error, disabling jni components: java.io.IOException: no apr in java.library.path Any suggestions came very much appreciated! Nothing wrong. I'll change the message. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Apache2.0.36/TC4.1/mod_jk Problem
On Sun, 5 May 2002, Anthony W. Marino wrote: After attempting to integrate Apache2.036/TC4.1/mod_jk2 (tc4.1connector source). I get the following when I try to run Apache2.0.36: Mod_jk2 uses a different config file and module name. I would advise you use mod_jk1 until we finish working on jk2, and more documentation is available. Use jk2 now only if you want to participate in the development - which would be great. I'll check in a httpd.conf fragment that can be used, for next milestone. Costin Can't locate API module structure `jk_module' in file /usr/local/apache2/modules/mod_jk2.so: /usr/local/apache2/lib/libapr.so.0: undefined symbol: jk_module ./apachectl start: httpd could not be started Relevant excerpt from my httpd.conf file: AddModule jk_module tomcat1 JkWorkersFile /usr/local/apache2/conf/workers.properties JkLogFile logs/mod_jk.log JkLogLevelinfo JkMount /*.jsp tomcat1 JkMount /examples/* tomcat1 Any help is appreciated! Thank You, Anthony -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] --- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jk_lb_worker.c patch
Bernd, At this moment I believe we should add flags and stop using the '0' value in the config file. Internally ( in the code ) - it doesn't matter, we can keep 0 or use the flag ( I prefer the second ). I'm waiting for your patch - it seems there is another bug that must be fixed before we can tag - but I hope we can finish all changes in the next few days. Costin On Mon, 6 May 2002, Bernd Koecke wrote: thanks for commiting my patch :). After thinking about it, I found the same problem like Mathias. It's a problem for my environment too. We have the same problem with shutdown and recovering here. I'm on the way of looking in jk2. The question for jk1 is, what want we do if the main worker fails because of an error? Because the normal intention of lb is to switch to another worker in such case. But for the special use of a main worker we don't want that (at least it is an error in my environment here :) ). My suggestion is to add an additional flag to the lb_worker struct where we hold the information that we have a main worker, e.g main_worker_mode. Because of this flag we send only requests with a session id to one of the other worker. And we could change the behavior after an error of an other worker and check his state only if we get a request with his session route. This would be easy if we set the main worker at the begining of the worker list and/or use the flag. But we need the flag if we want to use more the one main worker. But what should happen if the main worker is in error state? In my patch some weeks ago I added an additional flag which causes the module to reject a request if it comes in without a session id and the main worker is down. If this flag wasn't set or was not set to reject the module chooses one of the other worker. For our environment here rejecting the request is ok, because if a request without a session comes to a switched off node, we have a problem with our separated load balancer. This should never happen. We could make this rejecting be the standard if we have a main worker, but with a separate flag it would be more flexible. I will build a patch against cvs to make my intention clearer. Bernd [EMAIL PROTECTED] wrote: Hi Mathias, I think we understand your use case, it is not very uncommon. In fact, as I mentioned few times, it is the 'main' use case for Apache ( multi-process ) when using the JNI worker. In this case Apache acts as a 'natural' load-balancer, with requests going to various processes ( more or less randomly ). As in your case, requests without a session should allways go to the worker that is in the same process. The main reason for using '0' for the local worker is that in jk2 I want to switch from float to int - there is no reason ( AFAIK ) to do all the float computation, even a short int will be enough for the purpose of implementing a round-roubin with weitghs. BTW, one extension I'm trying to make is support for multiple local workers - I'm still thining on how to do that. This will cover the case of few big boxes, each with several tomcat instances ( if you have many G of RAM and many processors, sometimes is better to run more VMs instead of a single large process ) In this case you still want some remote tomcats, for failover, but most load should go to the local workers. For jk2 I already fixed the selection of the 'recovering' worker, after timeout the worker will go through normal selection instead of beeing automatically chosen. For jk1 - I'm waiting for patches :-) I wouldn't do a big change - the current fix seemed like a good one. I agree that changing the meaning of 0 may be confusing ( is it documented ? my workers.properties says it should never be used ). We can fix that by using an additional flag - and not using special values. Another special note - Jk2 will also support 'gracefull shutdown', that means your case ( replacing a webapp ) will be handled in a different way. You should be able to add/remove workers without restarting apache ( and I hope mostly automated ). Let me know what you think - with patches if possible :-) Costin The setup I use is the following, a load balancer (Alteon) is in front of several Apache servers, each hosted on a machine which also hosts a Tomcat. Let's call those Apache servers A1, A2 and A3 and the associated Tomcat servers T1, T2 and T3. I have been using Paul's patch which I modified so the lb_value field of fault tolerant workers would not be changed to a value other than INF. The basic setup is that Ai can talk to all Tj, but for requests not associated with a session, Ti will be used unless it is unavailable. Sessions belonging to Tk will be correctly routed. The load balancing worker definition is different for all three Ai, the lbfactor is set to 0 for workers connecting to Tk for all k != i and set to
Re: jk_lb_worker.c patch
Hi Bernd, It's great having you and Mathias working on this - I'll try to find a way to combine the 2 patches. I think it's best to have the minimum amount of modifications in jk1 to get things working. For jk2 I think we should do what's most flexible and powerfull - even if it requires bigger changes. Costin On Mon, 6 May 2002, Bernd Koecke wrote: Hi Costin, here is my patch for jk_lb_worker.c, jk_util.c and jk_util.h. It was diffed against the cvs. How does it work? 1) A new config param for lb_worker exists (main_worker_mode). Two values are possible: reject and balance. 2) This results in two new flags in lb_worker struct. If there was in minimum one worker with lb_value of 0 the flag in_main_worker_mode is set to JK_TRUE. JK_False if there was none. The second flag is reject. It is JK_TRUE if the config param above was set, JK_FALSE otherwise or if in_main_worker_mode is JK_FALSE; Behavior: If there was no worker with lb_value == 0 it should work as it used to. All workers with lb_value == 0 will be moved at the beginning of the worker list. It is possible to have more than one such worker. So you could have a standby server if the first main tomcat goes down. If a request with a session id comes in it will be routed to his tomcat. If that fails it will be routed to the main worker. If a request without a session id comes in it will be routed to the first of the main workers if that fails it goes to the next main worker. If there are no main workers left the reject flag is important. If it is set the request gets an error. If it is not set the lb_worker trys to route it to one of the other workers. All requests without a session id or with an id on a shutdowned node will only be routed to the main worker (reject == JK_TRUE). Its like a graceful shutdown, e.g. for node1. If the lb in front of the cluster didn't send a request without a session id to node 1 it will only get requests with a jvmRoute of TC1. After these sessions timed out, it could be updated, get a shutdown and startup. Even after startup it wouldn't get a request without a session. The lb in front of the cluster must do the first move and send the apache on node one a fresh request. Example workers.properties of node one: workers.tomcat_home=route to Catalina workers.java_home=$(JAVA_HOME) ps=/ worker.list=router worker.TC1.port=8009 worker.TC1.host=node1.domain.tld worker.TC1.type=ajp13 worker.TC1.lbfactor=0 worker.TC2.port=8009 worker.TC2.host=node2.domain.tld worker.TC2.type=ajp13 worker.TC2.lbfactor=1 worker.router.type=lb worker.router.balanced_workers=TC1,TC2 worker.router.main_worker_mode=reject For node two the lbfactor of TC1 is 1 and TC2 is 0. I didn't had a closer look at Mathias patch. It seems to be much shorter. We should take the best of both. This patch is only a suggestion. I'm not an experienced C-Programmer (I know my copy statements in validate are ugly, but I'm not very familiar with moving memory around :) ). Bernd [EMAIL PROTECTED] wrote: Bernd, At this moment I believe we should add flags and stop using the '0' value in the config file. Internally ( in the code ) - it doesn't matter, we can keep 0 or use the flag ( I prefer the second ). I'm waiting for your patch - it seems there is another bug that must be fixed before we can tag - but I hope we can finish all changes in the next few days. Costin On Mon, 6 May 2002, Bernd Koecke wrote: thanks for commiting my patch :). After thinking about it, I found the same problem like Mathias. It's a problem for my environment too. We have the same problem with shutdown and recovering here. I'm on the way of looking in jk2. The question for jk1 is, what want we do if the main worker fails because of an error? Because the normal intention of lb is to switch to another worker in such case. But for the special use of a main worker we don't want that (at least it is an error in my environment here :) ). My suggestion is to add an additional flag to the lb_worker struct where we hold the information that we have a main worker, e.g main_worker_mode. Because of this flag we send only requests with a session id to one of the other worker. And we could change the behavior after an error of an other worker and check his state only if we get a request with his session route. This would be easy if we set the main worker at the begining of the worker list and/or use the flag. But we need the flag if we want to use more the one main worker. But what should happen if the main worker is in error state? In my patch some weeks ago I added an additional flag which causes the module to reject a request if it comes in without a session id and the main worker is down. If this flag wasn't set or was not set to reject the module chooses one of the other worker. For our environment here rejecting
Re: Admin webapp save-to-XML
Craig, I did look at the code and I think I understand how it works. Save works by looking at 'getters' and generating the xml file. Sort of 'java bean xml persistence'. The generated file will have far more information that it needs ( there is no way to distinguish the 'defaults' ), it requires getters ( that wouldn't be a problem, but I wouldn't bet all components have them ), it doesn't distinguish between getters that refer to config and status ( i.e. runtime properties ), etc. And the biggest problem - I don't think this model can scale, or is flexible enough for the long term. I'm -1 on this - unless it is agreed and made clear this is just a temporary solution. I'm not sure that having the config data represented as a DOM tree (or a tree of JavaBeans, or any such structure) really helps decoupling all that much. On the way in (i.e. as Tomcat starts up), there still needs to be some logic that understands what components must be instantiated, and What's important is to have a layer between the config data ( including format, etc ) and the actual objects, and have all MBean setters go through this config layer. This is ( AFAIK - after spending a lot of time on this ) the only solution I could find. This will allow saving the options changed by the user ( not every getFoo() ), more flexibility in when is the config saved, preserve the structure ( including even comments ) of the XML file, etc. The way the config is read doesn't change - you can still generate the SAX events to drive the XMLMapper ( or just replace XmlMapper with walking the config and doing the calls explicitely )., In general, I believe long term we should move toward a solution based on Preferences ( or JNDI ), with XML used as an import/export format ( or for simple standalone configurations ), ( of course, Preferences are JDK1.4 only - and we'll need a wrapper that works in lower versions, like commons-logging. ) Again, this can be done post 4.1 ( and post 3.3.2 ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servletsManagerServlet.java
On Mon, 6 May 2002, Glenn Nielsen wrote: I agree, I added a Host config flag called deployXML which can disable this for context.xml files in the webapps dir. As long as this flag works for /META-INF/context.xml we are covered. Wouldn't be better to just separate the 'sensitive' config information from the sandboxed config ? The webapps/ ( including static and dynamic files, web.xml ) can be made accessible to users safely - i.e. give write permission in the webapp dir ( based on group, etc ). All sensitive informations should only be accessible to admins, so conf/ can/should be more restrictive. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servletsManagerServlet.java
On Mon, 6 May 2002, Craig R. McClanahan wrote: Context XML files are like the app config files in 3.3 -- they can contain any config parameters that could be found in server.xml inside a Context element. However, any Valve implementation classes you try to specify must exist in the server's classloader (i.e. in server/classes or server/lib) already to actually take any effect. They will not be loaded from the webapp's /WEB-INF directory. There's a lot that can be done only by using the internal classes to hook in some untrusted code. Messing with loggers for example would allow to override any file that tomcat core has access to. ( probably a bit hard to push content into it, but you get my point). The sandbox can protect you as long as you keep priviledged code separated. It seems unlikely to me (in general) that untrusted users would have any more access to the webapps directory than to the conf directory. It seems even more unlikely to me that untrusted users would be allowed to issue the Manager /deploy (or /install, which has the same level of flexibility) commands, both of which are password protected. I think it is a typical use-case to delegate the admin of applications, while keeping the main server config under control. The webapp is designed to work in sandbox, with 'webapp deployer' role different from 'server admin' role. A large site may have hundreds of webapps, each with different 'managers' ( with web hosting beeing the extreme case ). Having conf/ writable by the 'server admin' group while webapp/ ( or each virtual host's webapp dir ) writable by the 'webapp deployer' group is usually a good idea ( and the main reason for using conf/apps- in 3.3, instead of webapps/apps-xml ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk 1.2.0 / apache 2.0.35 error
That's a very stupid error message ( handler jakarta-servlet not found ). It should be changed to 'Can't connect to tomcat instance mywork' in the logs, and an 'application unavailable' in the page ( 'can't connect to tomcat' is fine too, but may reveal informations about the internal configuration ) +1 on changing it. Costin On Tue, 7 May 2002, GOMEZ Henri wrote: Hum I found the problem and it's weird. In httpd2.conf i used : JkWorkersFile /etc/httpd2/conf/workers.properties JkLogFile /var/log/httpd2/mod_jk.log JkLogLeveldebug JkMount /examples/* mywork But in workers.properties worker.list=ajp13 worker.ajp13.port=8009 worker.ajp13.host=localhost worker.ajp13.type=ajp13 So when a JkMount is found but for an unknown worker shouldn't we return a DECLINED and at least indicate that as error in log ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: GOMEZ Henri Sent: Monday, May 06, 2002 6:10 PM To: Tomcat Developers List Subject: mod_jk 1.2.0 / apache 2.0.35 error Hum mod_jk 1.2.0 didn't seems to works with Apache 2.0.35 Server error! Error message: handler jakarta-servlet not found for: If you think this is a server error, please contact the webmaster Error 500 hgo1.slib.com Mon May 6 17:20:25 2002 Apache/2.0.35 (Unix) mod_ssl/2.0.35 OpenSSL/0.9.6 DAV/2 mod_jk/1.2.0 I'll investigate this right now - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk2 (native2) autoconf preliminary works
On Tue, 7 May 2002, jean-frederic clere wrote: 1) What about moving scripts from jk/native to just jk ? It avoid duplicate between native and native2. That may bring problems: the configure.in normaly contains the files you want to generate. IMHO autoconf is justified only for jk2/apache1.3 ( eventually ). But if we decide to use it for apache2 and jni - then probably that may be a good idea. 2) What should be done for APR in Apache 1.3 ? Should we use external shared apr lib ? That is probably the best. Building mod_jk without APR is another option here. ( i.e. only with socket and what was in jk1 ). If we use apr, I think ( a bit strongly ) that we should use exactly the same library as apache2 does. APR libs should/could be installed in /usr/lib, /usr/include, and considered 'system' ( like glib, qt, nspr, etc ). If you build a non-threaded version, it shouldn't be called libapr.so in any case. Also I think the version that comes with Apache2's binary is to be considered the 'reference' - since Apr was not released independently, the apache2 package can be considered as the 'dependency'. Should we use static build apr (like does webapp) ? In all case should the apr for 1.3 must be with or without pthread ? Static apr may be a workaround, but I would avoid that if possible. libapr.so should be a 'deterministic' entity, if someone has a problem we should know he uses a certain version. 4) What about jni support ? Costin is the one that knows. It should use libapr.so, the one from Apache2 preferably. libjkjni.so should be generated - it won't be used from apache, but from java, and the same version of libjkjni can be used with any server ( apacheX, iis, etc ). In other words - you only compile libjkjni with Apache2 and APR, that's what java will use in all cases. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Question on JTC native/apache2.0 mod_jk.c
On Tue, 7 May 2002, Larry Isaacs wrote: #ifdef REUSE_WORKER I think it would be best to programmatically determine if tpool is usable to fetch a thread unique endpoint, and do something appropriate if it is not. Before I go digging into Apache 2.0 code, I would appreciate any suggestions or words of wisdom that might speed the process. Thanks. I think it's better to just undefine REUSE_WORKER ( and/or remove the code ). It is just a way to avoid few allocations and/or mutexes, there is no proof that this has any effect on performance ( and it shouldn't - compared with the socket operations this is nothing ). Note that the endpoint will still be recycled - this is just to use per-thread data for the objects used in processing the request. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk2 (native2) autoconf preliminary works
On Tue, 7 May 2002, Pier Fumagalli wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: If we use apr, I think ( a bit strongly ) that we should use exactly the same library as apache2 does. If that's provided with Apache 2.0... What if it's not provided with the web-server (AKA, apache 1.3?) We either don't use APR, or use the APR that is included with Apache2.0. For our purpose, that's the only 'stable' APR we can refer to, otherwise we'll be in a maintainance nightmare where everyone will have his own version/variation of APR. But not using APR with Apache1.3 is another choice - using 'native' apache1.3 pools for example instead of APR pools, native apache1.3 maps, etc will be even slightly better ( and using the same code as jk1 will be good too ) APR libs should/could be installed in /usr/lib, /usr/include, and considered 'system' ( like glib, qt, nspr, etc ). If you build a non-threaded version, it shouldn't be called libapr.so in any case. I strongly disagree with that, considering the bazillion of options that you have in building APR, and the different features that the library _can_ support (but doesn't all times)... Even when building Apache 2.0 the APR library is built differently depending on _how_ you build your Apache 2.0... Yes - that's the main reason for using a single libapr.so. If you have 2 programs using different libapr.so, say with different locking mechanisms - they'll not work togheter, each will use a different lock. It has never been released indipendently because of the API changes that (are still) going on to some extent... Look at the APR_ATOMICS, or the locking which got completely rewritten few months ago... The version that was shiped with Apache2.0 is stable and I think that's what we should use with jk2. We may have to change our code when Apache2.1 is released - but coding against one API in jk2 ( i.e. APR-head ) and using it with Apache2 ( with another APR API ) is looking for trouble. The idea that you can release a product without some parts still changing is crazy. I understand Apache2's APR is not called APR1.0 because people don't want to support that particular API in future - but we can't ship jk2 with dependencies on APR-head ( whatever that is ). Even if APR1.0 is released, we should use it only when a stable release of Apache2.x with APR1.0 is made. Static apr may be a workaround, but I would avoid that if possible. libapr.so should be a 'deterministic' entity, if someone has a problem we should know he uses a certain version. I believe that the dynamic build of libapr is better if you have plugins that your code needs to read: when you compile those, you link them against a library, rather than to a binary (which you can't easily do anyway)... I believe the main benefit of using shared libraries is not saving memory, but having consistency - the same code will be used in Apache2 and jk2. You can't get into a situation when Apache2 is locking in one way, and jk2 in another way. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk2 (native2) autoconf preliminary works
On Tue, 7 May 2002, jean-frederic clere wrote: APR libs should/could be installed in /usr/lib, /usr/include, and considered 'system' ( like glib, qt, nspr, etc ). If you build a non-threaded version, it shouldn't be called libapr.so in any case. But we have to deliver the apr.so corresponding to mod_jk.so. Pier is right... That is more easy to link apr staticly to mod_jk. Having to deliver 2 files instead 1 will only bring more problems. If you use Apache2 with mod_jk.so, then you _have_ a version of libapr.so. Having 2 variations of the apr code will bring more problems. If you don't use Apache2, jk2 will require you install a libapr.so - the same version that is shiped/taged with Apache2. First, you may install apache2 later :-) And second, that's the only stable/tested/deterministic version of APR that exist. If APR1.0 is released in the meantime, we'll have to decide what to do, but I hope an Apache2.1 will be released at that time too. If we would use Glib/Qt/NSPR - we would use the same mechanism, you would install one of those libarary ( each having one common goal with APR - of shielding you against OS-specific code ). Also I think the version that comes with Apache2's binary is to be considered the 'reference' - since Apr was not released independently, the apache2 package can be considered as the 'dependency'. We need one mod_jk.so for each version of apache2. Of course. But mod_jk for Apache1.3 should use the same version of APR as mod_jk for Apache2. And preferably the same binary. Apache1.3 doesn't include apr, so we can treat libapr as any other external library that a module depends on. Same for IIS - apr.dll from Apache2 is the stable/tested version, that's the API we use in jk2 until another stable release of apr is available. It may be tough to require IIS users to install Apache2, since apr.dll is not distributed separately ( but I can live with that :-). So we may have to include apr.dll and the headers in the jk distribution for IIS. That's my opinion at least - I don't see myself using/supporting a system where diferent components use different variation of a library. Autoconf is not a deterministic process - especially if you use a binary distribution, where the binaries may have been built on different machine. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk2 (native2) autoconf preliminary works
On Tue, 7 May 2002, GOMEZ Henri wrote: I must say I don't like autoconf too much :-) Ditto, ant is better than m4 but we couldn't ask people to have a jvm+ant+... to build native code ;( I agree - but doing autoconf twice ( once in APR, once for jk ) is _bad_. Not only because it's double-ugly, but because it can result in inconsistencies. If you have APR built once, all you need is a Makefile. I already added Makefiles for JNI and Apache2, for IIS we can use the DSP. Apache13 is the only open issue, and I think a Makefile using APXS will be the best solution, plus using the APR detection results. As I said, I'm happy with any other tool that simplifies the life of other people. autoconf chould just detect apxs location and grab java include (jni) JAVA_HOME is what's typically used to locate java. And setting one env variable ( or editing build.properties-like file ) is trivial and common practice for jakarta projects. ( curently you have to pass options or edit Makefile, but the settings can easily go in a build.properties include ). makefile.apxs allready works on native2 for apache 2.0 and apache 1.3 and configure just detect if APR should be used for apache 1.3. That's perfect. Just make sure it sets the defines that we need ( that select what we want ). And it works when apache 2 / apr includes are in /usr/include/apache2 and libapr in /usr/lib Perfect. As a secondary note, if anyone has some time we should look at sourceforge's ant-contrib and their CC task and eventually merge jkant into it, we shouldn't duplicate the effort. Hum, why didn't they include ant-contrib in ant cvs ? I think it's sometimes easier to work on sourceforge. Without Jon and politics. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
On Thu, 9 May 2002, Remy Maucherat wrote: Does servlet specification require you to call flush() to ensure that the client actually see the bytes? A. No, spec does not mandate this behavior for webapps. B. you have to flush your writer. Otherwise, because of timing problems, the bytes will not get written (bug 8916) If you instantiate a buffered writer yourself (instead of using resp.getWriter) to wrap around resp.getOutputStream, you have to flush it. So it's B. That's a java limitation BTW, if you wrap the writer returned by getWriter there's no way to get the info from the wraper's buffer ( if you use a BufferedWriter or something ). But if you just use the original writer it should work without a flush. ( and I think it does work ) Question 2 Where in servlet spec (or RFC 2616, your choice) does it allow the container to replace the message body or content-type header for an application that has set the status code to 2xx? A. It doesn't. It shouldn't. That would be clearly wrong. B. 200's and 204's are left alone, all other 2xx status codes are fair game to have their headers and body replaced. If the servlet didn't do anything other that set headers, and did not write any content, it doesn't contrdict any spec, and is desirable if the client is a web browser. B also. I'm not sure I agree - if the user want to send an empty page ( with a 2xx response ) that's perfectly fine. For 4xx he is required to define error-pages in web.xml if he wants, and the server may use whatever defaults ( since the user can tune the behavior in web.xml ), but for 2xx it's a bad idea to mess with the content. Some headers ( like Content-Length, Content-Type ) can/should be altered ( to insert the charset or set a default content type ) ( I'm not sure we are allowed to set a default content type if a servlet didn't suplied one - again if the user doesn't want one he should be able to get that ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
Steve,
In 8916 - if you use:
service() {
w= new PrintWriter( response.getOutputStream );
w.println(...)
}
If you don't flush, then you'll get no output.
That's not because of the servlet spec - but because of the way
PrintWriter works, it'll put your output in a buffer and that'll not be
written to the output stream.
If you use w=response.getWriter() than it should work without flush,
since the container does have access to the buffer ( in the first
case the container has no way to access your writer )
I agree that a 2xx response with empty content is perfectly valid
and shouldn't be modified, that's a bug.
Costin
On Thu, 9 May 2002, Steve McCarthy wrote:
Remy Maucherat wrote:
Question 1
Does servlet specification require you to call flush() to ensure that
the client actually see the bytes?
A. No, spec does not mandate this behavior for webapps.
B. you have to flush your writer. Otherwise, because of timing
problems, the bytes will not get written (bug 8916)
If you instantiate a buffered writer yourself (instead of using
resp.getWriter)
to wrap around resp.getOutputStream, you have to flush it.
So it's B.
Wrong again, Remy. And please stop introducing diversions like
instantiating a buffered writer yourself. The bug exists with the
Writer returned from the container.
Please go the the Java Servlet Specification, v2.2 Final Release.
Where does it put the burden of flushing buffer on the web application?
Please cite the chapter and section. Of course you can't because it is
not there.
Why is Tomcat 4.0.x is the only servlet container that requires this
strange behavior? Old JServ didn't. WebLogic doesn't.
I don't see how a reasonable developer can not answer A.
Also, what is this business you said about because of timing problems,
the bytes will not get written? Do other developers agree with this
statement?
Question 2
Where in servlet spec (or RFC 2616, your choice) does it allow
the container to replace the message body or content-type header for
an
application that has set the status code to 2xx?
A. It doesn't. It shouldn't. That would be clearly wrong.
B. 200's and 204's are left alone, all other 2xx status codes are
fair game to have their headers and body replaced.
If the servlet didn't do anything other that set headers, and did not write
any
content, it doesn't contrdict any spec, and is desirable if the client is a
web browser.
B also.
Please don't introduce another diversion that it somehow matters whether
the servlet set any body content or not. If it is 2xx, leave it alone.
It is reasonable even to leave 3xx responses alone. And for the
record, the bug exists if body content has been written.
Your answer again does not make sense. Here is a real-world example.
Say I write a WebDAV servlet. It writes text/xml. It returns 207,
which is not an error. Nor is this an invalid test case.
Now if the XML body is relatively short (smaller than whatever the
container sets the buffer size in the Writer), when my servlet
relinquishes control to Tomcat, Tomcat will stomp the body and change
the content type!
Please explain again to everyone why this is the right behavior.
Right now the only way to work around this behavior is to write a longer
message, which causes the container-provided Writer to internally flush
its buffer, or to force all servlet authors to manually call flush().
And remember, this is just a workaround. ErrorReportValve.java is still
trying to overwrite the response- it just can't do it once the response
is committed.
Your bug really is invalid, but you don't seem to be reading the comments.
Then when will you cite an RFC or specification to contradict my
argument? I give you overwhelming and specific evidence of a bug, yet
you don't contradict even one of my statements. I am confident that you
can't.
Still I wait for an rebuttal with technical merit. I can justify every
single assertion that I have made and back them up with RFC,
specification, or common sense.
-Steve
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
On Thu, 9 May 2002, Steve McCarthy wrote:
service() {
w= new PrintWriter( response.getOutputStream );
w.println(...)
}
If you don't flush, then you'll get no output.
That's not because of the servlet spec - but because of the way
PrintWriter works, it'll put your output in a buffer and that'll not be
written to the output stream.
Please note that the example uses a PrintWriter, and not a
BufferedWriter. Looking at the source of PrintWriter, all of the
println() methods write the data to the underlying OutputStream -
Are you sure you are looking at the right source ? I'm pretty sure
the PrintWriter is doing the buffering - most likely in the Char2Byte
conversion.
I did a lot of work on this area and I'm pretty sure I'm right on this,
there is a 8k buffer for everything that converts ( at least in
all VMs I worked with ). Jad may help you locate it.
characters are not buffered Writer level. If there is any buffering, it
occurs in the OutputStream provided by the container, and is therefore
available to the container.
You can probably check this by putting yet another wrapper -
new PrintWriter ( new MyOutputStreamWrapper( res.getOutputStream()),
and in MyOSWrapper you insert println() before calling the real stream.
I can bet you won't get any data passed to the output stream.
It isn't any different than obtaining the OutputStream from the
container, writing bytes to it, and then not calling flush on the
OutputStream:
service(...) {
OutputStream os = response.getOutputStream();
byte arr[] = getBytes();
os.write(arr);
// no os.flush();
}
It is different - again, there is a buffer. If you don't trust me try
yourself or use a dissasembler ( the char-byte converters are in sun.io,
they don't have sources ).
By the way, wrapping the application-level PrintWriter around the
OutputStream was intended to show two things:
1. Be a really simple example.
2. Demonstrate an inconsistent behavior that was present in Tomcat
4.0.1 where, by obtaining an OutputStream, you prevented
ErrorReportValve from obtaining a Writer, and thereby avoided having
your data trashed. I think that behavior may have changed in 4.0.4 and
beyond.
I do agree ErrorReportValve has a bug and shouldn't touch the
response if 2xx status, but that's a different story.
If you use w=response.getWriter() than it should work without flush,
since the container does have access to the buffer ( in the first
case the container has no way to access your writer )
I agree that a 2xx response with empty content is perfectly valid
and shouldn't be modified, that's a bug.
What is your opinion about 3xx codes?
I think it would be good to not touch them - the user does have a way to
generate 'nice' messages ( using error-code in web.xml ).
But I don't think the spec explicitely forbids us to change the body
on 3xx. I would make this configurable at least.
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
Hi Mathias, Thanks for the review. Few comments: Configure all Apache instances so they see all Tomcat instances, assign a higher priority to local workers on each Apache, therefore local What you set is the 'level' ( or proximity, distance, etc ) - lower numbers mean closer ( and higher priority, local worker ). I still need to add and verify the setters and check the various cases. workers, is called hwlb. The hardware load balancer checks the health of the Apache servers using a URI which is served by hwlb instead of lb, You may have noticed the 'jk_status' worker - it displays runtime informations ( still in progress - we need to agregate the statistics from all workers using shm, but the status of the workers should be fine ). It can be easily extended ( or a similar handler added ) so it can generate info that can be 'consumed' by a front load balancer or other tools. Like number of active workers and average response times. I am also investigating how we can use the number of active connections on each worker and the response times in the main lb, any idea would be wellcome :-) This setup solves my use cases at least, I don't know for Bernd's. Ok, but let me know if you find jk2 acceptable for your case and what is the minimal change to jk1 that we can do. I still have to merge your patches, I was waiting for more comments. I don't think we can/should backport the new code, it's far too much. There remains a related problem in jk_requtil in jk2_requtil_getCookieByName, as I mentioned several months ago on the list, the cookie extraction does not work for cookies whose format conforms to RFC 2169, that is the cookie value is enclosed in double quotes. Such cookie format is used by lynx for example. I had submitted a patch into the bug database but cannot find it anymore, I'll have to look up my archives. Please do, and send it to the list ( with PATCH ). I would apreciate 2 patches, one for jk1 and one for jk2 ( if the problem is in both ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Coyote] Coyote 1.0b9 release notice
On Fri, 10 May 2002, Remy Maucherat wrote: The idea is to have TC 4.0.4b3 be a last beta before final, and Coyote 1.0 would also be released at the same time. I don't know how much this is compatible with whatever work still needs to be done in JK2. If it's not, then Coyote 1.0 will be released later (but obviously, it needs to be before a 4.1.x Stable release). I am just running load tests with jk2, there are few minor tweaks I'll commit - but everything looks fine. The work on jk2 will continue - on the new features - but I think we are already functionaly equivalent with jk1, and that part is stable in both java and C. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [JK2] The IIS Connector is ( more or less ) working!!
On Sat, 11 May 2002, Ignacio J. Ortega wrote: Costin, Can you summarize a bit, what i need to build and use to have tc33 tc40 working with JNI? Not much - you do need APR, you should use the version that is bundled with Apache2.0 ( the DLL and includes ). Then compile with HAVE_JNI enabled, check the config of [vm], [worker.jni] and [channel.jni]. The [vm] objects deals with loading the VM - it needs classpath and all the params. [worker.jni] will execute a class ( calling main() ), you can include as many as you want ( but of course you need TomcatStarter if you want to run a version of tomcat ). [channel.jni] will forward the requests. You'll probably need to fix AprImpl a bit, right now there is a mod_jk.so hardcoded and probably few other things need to change to get it to work on windows. If you can wait till next week, I can help with this part. One important piece ( not related directly with jni ) is the jk_shm object and Shm on java side. Those will play an important role, and we need to get them working on windows. Shm is not a big problem, if we get into problems we can use JDK1.4's nio - i.e. no JNI is needed. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Coyote] Coyote 1.0b9 release notice
On Fri, 10 May 2002, Jon Scott Stevens wrote: My only semi-major complaint about Coyote (and I told Remy about this in person) is that the container now returns 503 errors until the servlet is started. Before, it would block (not quickly return a 503) until the servlet is finished starting. Remy said it was a result of the new threading that Costin put into things. Well, it is a result of the new threading in the sense that now it is possible to not block. If you want to bock there - it is quite easy to code this :-) I think returning 503 is a correct behavior too - it means 'resource temporary unavailable, try later' - which is exactly the case. Apache should return the same result if it can't connect to tomcat. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1] Add additional events
I plan to add additional events to the components start and stop methods: before_start, after_start, before_stop, after_stop. This has been suggested and discussed a while ago, but never actually implemented. Could you also add events for webapp add/remove/start/stop, and make sure the events are propagated up to coyote ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1] Add additional events
On Fri, 10 May 2002, Remy Maucherat wrote: I plan to add additional events to the components start and stop methods: before_start, after_start, before_stop, after_stop. This has been suggested and discussed a while ago, but never actually implemented. Could you also add events for webapp add/remove/start/stop, and make sure the events are propagated up to coyote ? That's already there (more or less). You need to put a container listener on the host and listen for Container.ADD_CHILD_EVENT (or REMOVE_CHILD_EVENT). The problem is propagating it via Coyote actions to jk level. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [JK2] More news about IIS
On Sat, 11 May 2002, Ignacio J. Ortega wrote: jk2 IIS plugin isapi_redirector2.dll passes all watchdog but 1, and all internals tests from tc33 but 1, the failure in watchdog is GetMaxInactiveInterval_01Test, the one in the internals test, is bogus, another test tied to Localized strings ( arghhh another one ), ;), so it works and does very well under ab -n 1000 -c 40 .. Great ! My tests have similar results with Apache2 on linux. Unfortunately JNI with JDK1.4 is a bit more difficult than I expected - it didn't seem to find the JNI .so until I removed the 'endorsed libs' from 4.x ( 3.3 didn't have that and it worked fine ). I still have the problem with a signal in JDK1.4/unix - but 1.3 seems fine in all combinations. I haven't run the full watchdog - I'm just trying crazy combinations ( 3 VMs x 3 containers x 3 channels, but only one web server so far :-) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2Makefile
On Mon, 13 May 2002, GOMEZ Henri wrote: We've got a problem here with all the automake stuff added. There is allready a Makefile.in which will scratch your Makefile after autoconf BTW, you're current Makefile seems ready for autoconf/m4 processing APACHE2_HOME, and the build.properties could be also used. So what to do now ? - There is a Makefile.apxs which works fine with both Apache 1.3 and Apache 2.0 - There is your Makefile and which could be processed by autoconf (from Makefile.in to Makefile) I'm a little puzzled here since we have now, many way to build jk2 for apache 2.0 (and 1.3) : jkant, Makefile (Apache 2), Makefile.apxs (AP2/AP13), and the automake stuff. What about using only 2 makefiles, one for dynamic (using apxs), one for static ? Ok. ( plus ant ) But I'm not sure I understand why do we need automake - if autoconf can generate only the build.properties file ( and probably a .h ). The makefile and ant should read the build.properties to get settings to use ( and that will also allow manual config ). I would like more info on what is autoconf detecting - and make sure we don't duplicate stuff that was detected by apache ( and end up with different settings for apache and jk ). In general, I would like the 2 'styles' work togheter - and the user is able to specify it's explicit preferences in build.properties-style, and autoconf will just guess the rest. It is very common to build the .so on a system and deploy it on another system ( the production server is not a build machine in most cases ), and I want to be sure the user can contol explicitely what options are used. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jk2: reconfig ( again )
I'm starting to have doubts about the current shm-based reconfiguration of workers. The solution is inspired from jserv - the scoreboard stores that status of each worker, when an apache instance detects the worker is down it'll update the shmem and everyone will know about this. That works fine in jk2 - in addition you can add workers, enable/disable workers from CLI. There are few problems: - the original attempt was to use JNI to allow java to configure that. There are numerous problems with that - especially on JDK1.4. - the model is hard to extend - I would like to be able to reconfig all components, not only workers. - if we use NIO to modify the config, we run into byte ordering issues. As a solution I used AJP-encoding for the shmem segments, but that's making the code more complex than it should be. - one of my goals was to abstract the config - and possibly allow a pluggable config source. The shm will make this more difficult. There is one other system that uses a similar aproach - Ksycoca, the new KDE configuration system. In this case, all text-based configs are read and a binary file is generated, with each process using the binary file. But even there, the config changes are made to the (ini) config files. If we don't find a better idea, I would like to roll back the worker config and use a simpler aproach: 1. All config changes are made to the original config source ( curently workers2.properties file ) 2. For each change, you must increment the 'ver' attribute of the changed object. ( or use a timestamp ). A config tool can easily automate this, but it's not very difficult for manual config. 3. We need a way to 'signal' that the config changed. We still need shm because we have multiple processes and all should get the information at the same time, and with minimal overhead. But only one int field must be modified, and we have more choices: - NIO/JNI with a java program. - a simple C program that just increment the shm location - jkstatus can check the file timestamp ( so after editing the file you would access /jkstatus ). Or use a dedicated worker. - we can check the timestamp periodically. Besides rolling back the current solution, we only need some enhancements in jk_config to get this working. Any better idea ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
On Mon, 13 May 2002, Bernd Koecke wrote: Sorry, I must say it again, for my environment it is an error, if a _switched off_ tomcat got a request without a sessionid or with a session from another node. Its not necessary that this tomact-apache tandem is In the current code ( in jk2 ), if a worker is in 'disabled' state it'll only get requests with sessionid, as you need. If it is not disabled, but has a higher level ( == distance ), it'll still not get any new requests unless all closer workers are in error state. update and start them up again. If there are no local/main worker I need an error response and no routing to a switched off tomcat. Its possible that this happens once per day. Setting the non-local workers in disabled state should do that. I know this might be a special environment. I spent some time in jk1 to build a working patch. Than I started looking in jk2. I'm not a good C Your patch looks ok. Would it be possible to remove the use of '0' as a special value, and keep only the main_worker_mode flag for that ? Also, what's the meaning of 'reject' flag ? Also it would be nice to get some documentation for the new settings. Regarding jk2 - I just want to know if the current solution is ok or what are still problems. For now the priority is getting the patch in jk1 so it can be released in 4.0.4 final ( so today or early tommorow I would like to close this issue ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
On Tue, 14 May 2002, Bernd Koecke wrote: The '0' as lb_value is needed to determine which are the main/local-workers. If we don't have this special value we need an additional config-flag with a list of the local/main-workers like in Mathias patch. Should I add an additional config-flag (I will take it from Mathias patch) or do we stay with the special '0' value? I think it would be a good idea, it'll make things cleaner. 'local_worker' would be allways selected, and if 'main_worker_mode' ( or maybe 'hw_lb_mode' ) no fallback will happen. The 'main_worker_mode' is not the same like the 'in_main_worker_mode' var in lb_worker struct. If 'main_worker_mode' flag is set to 'reject' in the workers.properties the reject var of lb_worker struct is set to JK_TRUE. The 'in_main_worker_mode' var of lb_worker struct is set to JK_TRUE if there is in minimum one worker with '0' as lb_value. That's a bit confusing. Maybe some better variable names are needed. 2 flags should be enough - 'local_worker' and 'local_worker_only' ( or something that makes it clear that if the flag is set, no fallback will occur but an error is returned for the hw balancer ). I'll implement the same thing in jk2, but I wait your patch for jk1. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2Makefile
On Tue, 14 May 2002, GOMEZ Henri wrote: The makefile and ant should read the build.properties to get settings to use ( and that will also allow manual config ). Do you agree having build.properties generated by autoconf ? +1. I don't mind if it also tries to 'guess' locations for the other packages we use ( like looking in /usr/share/java ). Is it possible to generate build.properties from build.properties.sample ( instead of .in ) ? Not a big deal, but it would be nice. It is very common to build the .so on a system and deploy it on another system ( the production server is not a build machine in most cases ), and I want to be sure the user can contol explicitely what options are used. For sure, as an rpm packager it's one of my primary concern I know :-) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
On Tue, 14 May 2002, Bernd Koecke wrote: Hi Costin, the new patch seems to work, but I'll test it more exactly tomorrow. Then I'll create the patches and the functional description. In short, the patched lb_worker uses an additinal flag on the other workers (e.g worker.ajp13.local_worker=1) to determine if it should be moved to the beginning of the balanced_workers. So we don't need to deal with two lists in lb_worker and the lb_value '0' has no special meaning. The flag for sending requests only to local workers is 'local_worker_only' on the lb_worker. More when the patch is tested and ready. Ok. I already commited part of the changes for jk2 - but my version is called 'hwBalanceErr', on worker_lb. If 0 normal selection of non-local workers takes place if all locals are in error state. If non 0, we'll return the value as the error code - for a front-end balancer to detect and stop forwarding requests for this instance. I think that's the behavior you need - and it also allows customization for the returned error code. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: local worker patch for JK1
On Wed, 15 May 2002 [EMAIL PROTECTED] wrote: Hi, there is something that bothers me in the patch Bernd sent, that is the local_worker property of workers, I think the concept of local worker is linked with that of load balancing worker, and not to that of worker. Nothing forbids to have an ajp13 worker in several load balancing workers, if the local worker property is linked to the ajp13 worker, the worker will be considered local for every load balancing worker it appears in which is something I think should be avoided. I agree, but this is too complicated. If anyone really need this feature ( or different lb factors on different load balancers ) we can add more settings. Most people use a single lb, and things are already complex if you have multiple lbs. Let's leave this for jk2.x. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: found 3.3-head thread problem
On Wed, 15 May 2002, Keith Wannamaker wrote: Remember last week when I mentioned the thread problem in 3.3-head? In PoolTcpEndpoint, when there is a SocketException, we log a non-fatal error message. The problem began when Remy pointed the string manager to an empty bundle. StringManager.getString will return a null rather than throw a missing resource, and a null check is not done by JDK 1.3 prior to trying to format the message. The resulting npe terminated the thread. Gradually over time, all accepting threads are terminated. So, no big deal, add the missing resources, but I'm wondering, why don't we check to see if our accepting thread count dwindles or vanishes, and start more up? Is this logic non-existant or broken? Great finding. I would also add another round of try/catch for Throwable to catch any other NPE in the catch(). Not sure about the logic - it is supposed to detect and start new threads... If you can take a look... Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ant tools for 3.3
On Wed, 15 May 2002, Keith Wannamaker wrote: I've written some ant tools that allow builds to populate the Tomcat work directories with precompiled JSPs. I'm trying to decide a home for them, if any, and was thinking of a new package org.apache.tomcat.ant .. any other preference? +1 Just make sure the build.xml is able to exclude the tasks from the 'main' jars and create separate jars for the new tasks. Also - please include META-INF/ant.properties ( for multiple taskdefs with resource= ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ant tools for 3.3
On Wed, 15 May 2002, Keith Wannamaker wrote: I've written some ant tools that allow builds to populate the Tomcat work directories with precompiled JSPs. I'm trying to decide a home for them, if any, and was thinking of a new package org.apache.tomcat.ant .. any other preference? BTW, for jasper tasks: it may be a good idea to include them in jakarta-tomcat-jasper. Maybe we'll generalize them and make it work with the new jasper. I haven't looked at the new mangler, but porting the 3.3 mangler or supporting multiple styles in the tasks would be usefull. ( I think it's reasonably easy to use the new jasper with 3.3, modulo few minor changes - and porting the tag pooling if it hasn't been done yet ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Switching javac for jasper 2
com.sun.tools.javac.Main doesn't seem to be in JDK1.2.x, and that's the target platform, isn't it ? I think the best solution for javac is to just bundle ant.jar and use it programmatically ( i.e. new Javac(), etc ). The introspection and hacks required to support multiple compilers are just too ugly - and they already have good solutions in ant. We already have enough complexity to support jikes. Costin On Thu, 16 May 2002, Kin-Man Chung wrote: Tomcat has been using sun.tools.javac.Main as the default java compiler for compiling the java files generated by Jasper. This compiler is essentially a JDK1.2 compiler, current deprecated and unsupported. The warning message Note: sun.tools.javac.Main has been deprecated is probably familiar to a lot of people. The compiler to use is com.sun.tools.javac.Main. The only thing that prevented us from switching over to this one is the fact that it does not allow a PrintWriter to be specified for error messages that it may produce, which essentially force tomcat to synchronize all compilation processes, a big performance hit. I believe that J2sdk1.4.1, currently targetted for FCS in fall 2002, will provide a javac.Main which allows us to specify a PrintWriter, essentially removing the need for synchronizing the compilation. We definitely will use that when it becomes available. However, I recently runs into problem with sun.tools.javac.Main which surfaces when a jsp page gets large. Sometimes it produces bogus errors, and somteitmes it even produces bad class files that cannot be loaded by VM. I am contemplating switching over to using com.sun.tools.javac.Main now, for 4.1 (jasper2). If there are objections, please let me know. BTW, anyone know the best way to capture javac error messages written to standard err stream? I want to avoid calling Runtime.getRuntime().exec if there is a way. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Switching javac for jasper 2
On Fri, 17 May 2002, Kin-Man Chung wrote: com.sun.tools.javac.Main doesn't seem to be in JDK1.2.x, and that's the target platform, isn't it ? I believe for 4.1.x, it should be 1.3.1 and above. Like I said, 1.2 javac is currently unsupported and deprecated in 1.3 and 1.4, and contain bugs that are hard to work around. Can't image people currently using jdk1.2 wouldn't want to upgrade. I believe the target platform is 1.2, not 1.3.1 ( at least acording to RUNNING.txt ). I don't remember any vote that changed that. There are still platforms without a JDK1.3.1 or above. Most free VMs are still strugling to support JDK1.2 fully ( gcc or kaffe for example ). Many productions sites can't upgrade at will. I think the best solution for javac is to just bundle ant.jar and use it programmatically ( i.e. new Javac(), etc ). The introspection and hacks required to support multiple compilers are just too ugly - and they already have good solutions in ant. I'll look into that. But even if ant.jar is used programmatically, eventually it still start another process to invoke javac, right? Plus it's yet another jar to be bundled with tomcat; do we really want that? Ant doesn't start another process to invoke javac unless you explicitely ask for it ( by fork=true ) or use jikes or another native compiler. Between including 'another jar' that supports most javac compilers and changing the code to support only JDK1.3.1 and JDK1.4 compilers - I think the choice is pretty simple. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Coyote] 1.0 Final release ?
On Fri, 17 May 2002, Remy Maucherat wrote: I think there are no remaining issues with the core API, the TC 4 adapter and the HTTP/1.1 protocol handler. The last issue that needed to be addressed was the incompatibility with the daemon and some small behavior differences with the old HTTP/1.1 connector. I'd like to get this release out before releasing 4.0.4 Final which would include it. 4.1.x could try to stick to Coyote 1.0 for some time, also. I don't know about the status of the Java parts of JK 2 and the Tomcat 3 adapter. I didn't see big changes there, so I assume they're ok. Please let me know. I'll start the final release process with a RC 1 release. +1 I have one small change - adding a new ActionCode for CLIENT_FLUSH - to notify jk layer that flush() was called explicitely by the user. It doesn't change any of the existing code, just add a field and a method. Let me know if I can quickly check it in. Costin ballot [ ] +1 [ ] -1 /ballot Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Status of JK2
On Fri, 17 May 2002, Anthony W. Marino wrote: Costin, If you can give me an idea what I need to do to get it built/running with apache2/TC4.1.2/SuSE7.3 I would be more than happy to do some testing if not more. cvs co jakarta-tomcat-connectors cd jakarta-tomcat-connectors/jk Copy build.properties.sample to build.properties and edit to fit your paths. There are 2 big options: configure and ant. I typically use ant - if you have libtool and gcc installed it should work fine. $ cd native2 $ ant or $ configure ; make This should compile j-t-c/jk/build/jk2/apache2/mod_jk.so. Add a LoadModule to apache's httpd.conf, copy j-t-c/jk/conf/workers2.properties to APACHE_HOME/conf - and start apache. You should be able to see http://localhost/jkstatus - that's the first page to try. Then start tomcat, play with examples, etc. If all this works - please write a nice doc with what you actually did and send it as a patch :-) Note that for tomcat you can use either the old connector ( in 3.2, 3.3, 4.0.x ) or the new coyote-jk connector ( 3.3, 4.x ). Costin Thank You, Anthony On Fri, 17 May 2002, Anthony W. Marino wrote: I'm now running TC4.1.2 and want to use mod_jk2/apache2 for the early stages of my project however I'm not certain what the issues are or when it might become production quality or what I see the empty download areas set up for the various connectors which I hope is an indication of precompiled drops soon to be available. Jk2 is pretty close - I am running all kind of tests, Henri is finishing the configure, Nacho got it running on IIS. Except for iPlanet support, most of the features are ready or pretty close. I'm only doing 'cosmetic' and bug-fixes now - plus documentations for the new config, auto-generation of config from web.xml, etc. I think the release of jk2 depends only on the ammount of help we can get with the build/testing/docs. After we're in a decent state with the docs and the build we can release betas/milestones. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Status of JK2
On Fri, 17 May 2002, Anthony W. Marino wrote: ant all in jk dir gives me the same error: /mydirpath/jakarta-tomcat-connectors/jk/build.xml:100: Could not find file /mydirpath/jakarta-tomcat-connectors/coyote/build/lib/tomcat-coyote.jar to copy. You need to build coyote first ( cd j-t-c/coyote ; ant ). Probably that will require tomcat-util :-) There is a build.xml in j-t-c/ that will build all of them. Or you can try the 'configure' path :-) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Status of JK2
On Fri, 17 May 2002, Anthony W. Marino wrote: I'm now running TC4.1.2 and want to use mod_jk2/apache2 for the early stages of my project however I'm not certain what the issues are or when it might become production quality or what I see the empty download areas set up for the various connectors which I hope is an indication of precompiled drops soon to be available. Jk2 is pretty close - I am running all kind of tests, Henri is finishing the configure, Nacho got it running on IIS. Except for iPlanet support, most of the features are ready or pretty close. I'm only doing 'cosmetic' and bug-fixes now - plus documentations for the new config, auto-generation of config from web.xml, etc. I think the release of jk2 depends only on the ammount of help we can get with the build/testing/docs. After we're in a decent state with the docs and the build we can release betas/milestones. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jk2.shm (2,147,483,647 bytes)
On Sun, 19 May 2002, Anthony W. Marino wrote: Using connector source from cvs, from yesterday afternoon, I built mod_jk2.so for use with Apache2.0.36/TC4.1.2/SuSE Linux. I copy workers2.properties into a2/conf and then add a LoadModule statement to a2/conf/httpd.conf. TC starts seemingly ok then after a minute or so I start httpd which is extremely slow. I notice an extremely large file a2/logs/jk2.shm which eventually consumes almost all my available disk space (2,147,483,647bytes) I had to shutdown both httpd then TC. Can you add 'debug=1' in the [shm] section ? What's the size param ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JK2/Coyote Connector Testing Effort
On Mon, 20 May 2002, Anthony W. Marino wrote: (TC4.1.2/JK2/Apache2) 1) Is it required that for a mod_jk2.so build/distribution that the entire set of coyote jars also be distributed when the build is based on a new j-t-c download from cvs? The C and java sides are independent of each other, you can use the C module with any version of tomcat from tomcat3.2 ( up to coyote ). There are few build 'glitches' - I'll try to improve it as soon as I get back. 2) Can Ant1.5b1 be used to build existing files? Any ant after 1.4 should work, as well as configure ( i.e. ant is not the only way to build jk ). The current ant tasks for building C work reasonably well - and I think it's a good idea ( for some reasons I prefer to write logic in java rather than .sh or m4 ). However libtool/configure/make remain a solid solution. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Using NIO package for Tomcat connector?
On Mon, 20 May 2002, Setera, Craig wrote: Has there been any discussion on building a connector around the NIO package in Java 1.4? I just read an interesting article in the latest Java Developer's Journal about a web server built using this support and it looked excellent. Using NIO would lower the number of required threads and buffers/objects that would need to be created. Obviously it would be dependent on 1.4, so it could not be the default connector. But, I believe it would be nice to have the option. Yes, we discuss it few times. For HTTP it won't give us too much, even if we do pool() we still need to use the same thread model. But for the JK2 connector I believe using direct buffers would give us a nice performance gain, and I'm working on this. Direct buffers are IMHO the most important aspect of NIO, it provides a much better way to communicate between java and C. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JK2/Coyote Connector Testing Effort
On Mon, 20 May 2002, Anthony W. Marino wrote: Costin, I've experienced all kinds of build problems using Ant however it's what I prefer to use and I'll pass along the changes when finished. Ant is what I prefer to use, but the final goal is to make it easy for people to build mod_jk - if ant gets in the way, you should use the makefiles and autoconf. There is another project ( ant-contrib on sf.net ) doing tasks to compile C code with ant - the syntax is a bit different, but it could be used as well. After we're done with jk and this release, I'll spend some more time with the tasks trying to integrate/merge with those - any help would be great. The reason I'm interested in this - I think java is a more powerfull language than m4 and .sh, and it may be worth having a build system that most people can understand. I admit having troubles reading the libtool code ( and I have some .sh experience ), and not liking m4 too much. Are you going to be gone for long??? Just have a good time, regardless of what/where! I'll be back in 2 days ( unfortunately :-), I'm visiting few friends on the east coast. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New committer: Denis Benoit
On Tue, 21 May 2002, Remy Maucherat wrote: I'd like to propose Denis Benoit Denis.Benoit at fbn.ca as a committer on the Tomcat project. Denis has contributed patches to Jasper 2 which brings an impressive performance improvement when using JSP pages which rely heavily on tags, such as the administration web application available in Tomcat 4.1.x. He appears willing to spend time to further improve Jasper 2 performance. +1. Nice work ! Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: j-t-c/jk/native2/build.xml: if=linux
On Tue, 21 May 2002, Anthony W. Marino wrote: Where/when does the linux property get set? In your build.properties. Hopefully we'll be able to automate this ( extract it from System properties ), or at least document it better. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: j-t-c/jk/native2/build.xml: if=linux
On Wed, 22 May 2002, Anthony W. Marino wrote:
Why not have it automatic and add the property as a global property in the
relevant build files as follows:
property name=${os.name} value=${os.name} /
Then make appropriate changes to if=... (ie; Linux not linux)
That would work, good idea. I'm don't like too much using substitution in
the property name - I would rather use the condition tasks.
( I can't believe I didn't think about this... )
Costin
The only properties that should be in the build.properties file are user
preferences and NOT hardcore system relevant properties that can be
ascertained with a built-in property.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c
On Thu, 23 May 2002, Ignacio J. Ortega wrote: Added few #ifdefs to make it compile with my version of MSVC ( probably an old one ). It's not a new MSVC version, You need to download the Microsoft Platform SDK, to get the includes and libs needed to compile an isapi_redirector2.dll with all the later developments, mainly to be able to specify tomcatAuthentication=false on iis5, that is to be able to use Native IIS Auth on tomcat, so i would prefer very much to add the needed info to some readme, than to permit to build a non Complete i_r2.dll Well, I don't think it hurts too much to allow a build with the 'plain' MSVC ( just 3 #ifdefs, the code is reasonably clean ). I'll try to get the SDK, but if it requires me to signon ( to passport :-) - I'll give up. I assume some ISAPI servers ( and PWS ) do not support the new stuff anyway. I'm fine with requiring the MP SDK if it's easy to download, but at least for now I would prefer beeing able to compile with a plain MSVC. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New Committer Dan Sandberg
+1 Costin On Thu, 23 May 2002, Bill Barker wrote: I'd like to propose Dan Sandberg (x at cs.stanford.edu) as a new Tomcat committer. He has already put in a great deal of work in re-factoring the SSIServlet in Tomcat 4.x, and seems to be willing to further contribute to working on this. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common list.mk
On Fri, 24 May 2002, jean-frederic clere wrote:
${JK}jk_channel_jni${OEXT}\
That would require to have J2SE to compile mod_jk2.
No, it has an
#ifdef HAVE_JNI
// jni-specific code
#else
// empty factory
#endif
I did that to get rid of the conditional compilation of files and
simplify the makefiles, all files must be compiled.
Based on HAS_APR and HAVE_JNI some sections of code will not
be compiled.
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common list.mk
On Fri, 24 May 2002, jean-frederic clere wrote: I did that to get rid of the conditional compilation of files and simplify the makefiles, all files must be compiled. Sure if jk_channel_jni.o is not linked in mod_jk2.so jk2_channel_jni_factory is unresolved! If HAVE_JNI is undefined, a dummy factory will be linked in ( that will just mark the component as disabled ). This also allows the config system to maintain the configuration for the component. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New Committer Dan Sandberg
That leaves me perplexed for several reasons... First, it's the first time I see a commiter rejected - without any reference to the quality and importance of his contribution, but some new member's standard we don't know about. Dan put the SSI system in a decent shape, that's similar with the contributions many others have done to become commiters. Second, if the 'members' and/or PMC has anything to say, I believe it should do it directly and in a public forum. Beeing talked about behind our back is not very comfortable. I nominated quite a few of the current tomcat commiters, and each of them made important contributions to tomcat. I used the same 'standards' that Bill used when proposing Dan. I believe we deserve some explanation from the 'members', I'm quite unhappy about this whole issue. If there are some new quantitative standards for becoming a commiter ( or a member ) we should know about. Costin On Fri, 24 May 2002, Pier Fumagalli wrote: Bill Barker [EMAIL PROTECTED] wrote: I'd like to propose Dan Sandberg (x at cs.stanford.edu) as a new Tomcat committer. He has already put in a great deal of work in re-factoring the SSIServlet in Tomcat 4.x, and seems to be willing to further contribute to working on this. -1 Sorry, but 7 messages posted to the -dev mailing list, and two patches don't make him reach my bar... I hate to be the PITA, as always, and I don't have anything against Dan or the patches he submitted to SSIServlet, but I believe that this group (as noted on the members meeting this Tuesday) is giving away committer privileges a little bit too easily... That's my $ 0.02 anyway... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Proposal] Tomcat and Cactus (Repost)
On Fri, 24 May 2002, Vincent Massol wrote: I'm reposting in the secret hope that I got no response to this email I sent last week because no one saw it in the flood of Tomcat emails ! If I get no answer this time, I will understand that no one finds this of interest and will try again in 6 months - 1 year :-) I think it would be a good idea :-), there is already far too much going on, with all the new features and changes ( jmx, 4.1, jk2, jasper2, coyote, etc ). Costin Thanks -Vincent Hi Tomcat developers, This is a proposal to bring Jakarta Tomcat and Jakarta Cactus (http://jakarta.apache.org/cactus) closer. I hope you'll like it. (0) Rationale Jakarta Cactus is a unit testing framework for testing Servlet, Taglibs and Filters. Jakarta Tomcat is a Servlet engine (Servlet, Taglibs, Filters). They are both part of the Jakarta community. At the moment, there are no existing Servlet container that have an easy way to unit test Servlets. The idea is to bring this ease of use to Tomcat by making it easy to use Cactus within Tomcat (in other words, add a unit testing service to Tomcat). (1) Scope of the proposal a) To bundle Cactus within Tomcat so that it provides a unique ease of use for Tomcat users who wishes to test their servlet code b) To make Cactus the official Tomcat test framework for end users (1) From the point of view of Tomcat users By providing the bundling defined in point (2) below, Tomcat end users would only have to do the following to test their code (see http://jakarta.apache.org/cactus/1.4/howto_tomcat.html, steps 4 to 6) : a) Create Cactus test classes in their WEB-INF/classes directory b) Open a browser and type the URL of the Cactus test runner, passing the name of the test class (see the link above for details) (2) Cactus bundling in Tomcat Bundling Cactus in Tomcat means (see steps 1 to 3 on the above link) : a) Adding the following jars to common/lib : cactus.jar, junit.jar, httpclient.jar, aspectjrt.jar (total of 423 KB) b) Adding the Cactus servlet test runner and redirector servlet and mappings in conf/web.xml (3) Versions The target Tomcat version for this proposal is 4.0 and greater. The Cactus one is 1.4 and greater (note that Cactus 1.4 is not released yet and is still in CVS - It can be downloaded from the nightly build). Comments, ideas ? Thank you -Vincent (from the Cactus team) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Proposal] Removing 64K limit in jasper 2
I don't think the overhead of calling a private/final method is very big, especially with hotspot or any decent jit. If this turns to have an impact, we can turn it on only for pages with many tags, but I think it would be fine for all pages ( without scriptlets ). BTW, given that the logic in a JSP page without scriptlets is quite simple, using a state machine may also be a good solution. I mean saving a pre-processed/binary form of the JSP as data, and using a sort of interpreter. I have big doubts on the benefits of using a compiled form for this kind of data-driven stuff. That's just an idea - it may also work well without even compiling the page to .class for most non-scriptlet pages. Costin On Fri, 24 May 2002, Kin-Man Chung wrote: The JVM limits the size of a method to less than 65535 bytes. This limit can easily be reached by a JSP page with 50-80 custom tags, depending on the javac compiler and the complexity of the tags. The use of largefile option delays reaching the limit a little, but not by much. That's one of the reasons largefile option is not implemented in jasper 2. My proposal to solving this problem is to generate codes for a tag handler (including its body) to a separate method. This is only feasible if the tag action element and its body does not include any scripting elements. The current trend (in the coming JSP1.3) seems to be moving to scriptless pages, so this is not as restrictive as it appears. I don't have a detailed design yet for Generator, but I don't see any obvious problems. The recent change in flattening out the try/catch blocks complicates things a little, but they are manageable. There is obviously some performance trade-offs. I really don't like using a compilation option to turn on/off features, especially if it is used only to get around limitations the users don't care. I think jasper can make code generation decisions based on the number of tags (both sequential and nested) in a page. I plan to make experimentation ease by having parameters (such as number of tags, size of tag body) that can be adjusted, and hopefully to arrive at a balance between limiting the size of a method to 64K and some reasonable performance. Comments? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New Committer Dan Sandberg
On Fri, 24 May 2002, Pier Fumagalli wrote: Just one question on this. Being a committer implies that you're going to have the right (and the due, of course, like in any good democracy) to (for example) elect PMC members, have -also- a some sort of responsibility over what you do, and what others do, meaning code reviews, deciding on the future of the whole tomcat project, voting on future release plans and such... As I said, this is not only a right, but also a responsibility. As a committer you _should_ be doing that. Now, my question is, do you want _at_this_point_ to have that responsibility? Are you interested? I don't want to sound bad, but hey everything comes at a price :) :) :) Most tomcat commiters review only a small ammount of the commits, that is relevant to what they know. Voting ( or beeing voted ) in PMC is optional. If you want to know the real price of becoming a commiter - it's loosing all control over the code you write, having to play flame wars and grow a thick skin. And you may spend many weekends doing work that is just thrown away. Pier is right in this aspect - and I fully agree with him that beeing a jakarta commiter comes at a much bigger price than you may think. If you want my advice - create a sourceforge account, do all the work on SSI there, and have fun. ( and maybe give access to other tomcat commiters who are interested to work on SSI ). Costin (I just want to show how committing to a particular codebase, sometimes, might be different from the whole kit'n'kaboodle that being a committer involves)... D.Scope. Must a commiter have scope to the entire project? Can't the access file be changed only in the o.a.c.ssi directory and the servlet directory? Would this address any concerns? Technically it would be feasible to implement that feature, but administrivia would become utterly complex. Thank you _very_much_ for taking part to all of this :) :) :) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
-1 If someone doesn't want to be involved in the voting - he can do exaclty that, abstain. If someone doesn't want to support a particular release - he can abstain from the release vote( or vote +-0 ). If you spend time and write code for a project and are willing to maintain/support - and if the people on the project vote you in, you have the same rights as all the other people on that project. I do agree ( and I advocated for this a lot ) on lowering ( or eliminating) the walls between projects, so jakarta commiters can commit code in any jakarta project ( subject to the normal project rules ). Some people didn't agree with that even for commons, and I accepted the fact. If you are a commiter - you have the same rights with all other commiters. If you don't want to exercise some rights - it's your choice. Costin On Sat, 25 May 2002, Pier Fumagalli wrote: Chatted with a lot of people, seen many, different development models, went around, asked, talked, and I believe I have a pretty decent picture, and maybe even a solution... So the major topic of discussion is that I perceive a substantial difference between being able to commit code to a CVS repository, and being a committer committer, with all dues and responsibilities that this role concerns... For example sometimes someone might want to have commit access just because he is working for a company that deals with a particular project in Apache (we've seen this happening several times with some projects such as Xerces and Tomcat), but he really doesn't care about the whole fuzz of Apache and stuff, and once the employment contract ends, the relationship with Apache terminates as well (I don't need to enumerate all those examples along those lines). One other example, if we didn't have Henri building RPMs for basically all Jakarta projects (and others), or if Henri wasn't a committer on Tomcat, don't you think that he would deserve committer status even if he's not tied to any particular codebase? We had this problem in the current election of the members, Sally Khudairi: Sally doesn't code, but she was involved with the ASF since before it was even created as a press organizer. Does she deserve to be a member of the foundation? Even if she doesn't code? Yes she does, IMO (and she was elected and nominated a member today)... So, IMO, there's a great difference between being a coder, and being a member of the Jakarta community, at least in my opinion. There might be coders who are not involved with the community, and there might be non-coders who are much involved with it, want to participate, are active and deserve to be committers... Our current structure doesn't allow that to happen, both things. If you need to write code in a particular source-base, and you need CVS access, you are automagically made a committer, even if you don't care about much else, and if you're very much involved with the overall project, but not tied to ANY whatsoever codebase, and really, don't want / can't do it. So, given this little background, I would like to ask to the PMC, and all other committers, if others agree that we should splitting the committer figure in two parts: - contributor: a contributor is someone who has access to a particular CVS tree, but for any reason doesn't want/need to be involved with the whole Jakarta community. He just wants to code his little bit and live a long life. - member: is someone who is involved with the Jakarta community, somehow, somewhere (might be just giving a great deal in supporting users of our projects, or providing extra value to projects, like guidance in respect to overall specifications, binary builds). He is effectively a member of the community and has all the rights and dues of every member, such as participate in the election of the PMC. And redefining the figure of the committer as follows: - committer: is a contributor, but also a member, therefore he has all the privileges and dues of a contributor (having CVS access, and overlooking the code he's contributing to) and of a member (can vote for PMCs, should participate and contribute to discussions on the overall structure of Jakarta). I believe this makes sense, more sense than what we have now, also because we've seen that happening in the ASF for the very first time with a non-coding member. Comments please? Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New Committer Dan Sandberg
On Fri, 24 May 2002, Denis Benoit wrote: All that being said, if it would appear preferable to some that my name be removed from the CVS commiters list, I would not mind a bit. I have just Denis, your contributions so far have been impressive. If anyone wants to remove your name from the CVS commiter list, he'll have to remove mine first. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New Committer Dan Sandberg
On Fri, 24 May 2002, Pier Fumagalli wrote: If you want my advice - create a sourceforge account, do all the work on SSI there, and have fun. ( and maybe give access to other tomcat commiters who are interested to work on SSI ). Very constructive, Costin, indeed... See my next email (at least I'm trying to propose something)... I believe I proposed something as well. Sourceforge is an excelent place to write code and have fun. And you can make the projects as open as you want and have the same technical resources ( or more ). There are quite a few projects there that are doing pretty well ( JBoss ? ). I'm playing with ant-contrib and cpptasks right now, they even have a nice community. I think Coyote started as a sf project as well ( Remy ? ) Same for Cactus, etc. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
On Sat, 25 May 2002, Pier Fumagalli wrote: If you are a commiter - you have the same rights with all other commiters. If you don't want to exercise some rights - it's your choice. Hola, you tend to forget a part I'm stressing out quite hardly... It's not only rights... It's also dues, right? Yes, the 'due' to spend weekends writing code or answering emails or reading flame wars. Give me a break with the big 'due' to vote or have a say over how the project you're involved with. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Change to the 3.3 API
+1. Adding new methods is perfectly fine and backward compatible. BTW, my proposal to freeze the API was based on the fact that I felt it is good enough and I couldn't think any significant improvement that would be worth the change. If you think different or have some good ideas - we can reopen the issue ( but I would like to keep backward compat as long as possible ). Costin On Fri, 24 May 2002, Bill Barker wrote: I'd like to add a new method (for now called 'preInitCheck') to the API to be called before the check for calling the init method. The current JspInterceptor.requestMap would be split between the new preInitCheck method (which would handle the compile), and the requestMap (which would register the servlet). In light of bug #7654, we may want to have a 'preInitCheck' and 'postInitCheck', but I'm still not convinced on how important this case is. This is a proposal, since there was a consensus to freeze the API. I'm not looking for people to help (although volunteers are always welcome), since the changes are simple enough. The only known bug that this fixes is the rather obscure one that currently a JSP page that is accessed from a NamedDispatcher will not be re-compiled. More importantly (IMHO), this will separate the JSP logic from ServletHandler and put it firmly into JspInterceptor where it belongs. Of course, I'm expecting that Pier will veto this on the grounds that he can't be bothered to keep up with the 3.3 development. ;-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Vicious Abuse?
On Sat, 25 May 2002, Pier Fumagalli wrote: Jeff Turner [EMAIL PROTECTED] wrote: .. and thankful that people like Costin persevere in spite of rather vicious abuse. Vicious abuse? All I am proposing is to add greater flexibility to the freedom of those who are involved with the Jakarta project. All I'm proposing is to accept the idea that we might have coders who don't care about new projects or PMCs, they just want their code done, or that we might have important resources out there who might want to get involved with this project but cannot be tied to one particular code base? Is it a vicious abuse to ask Sally to become an ASF member ALTHOUGH she doesn¹t know how to code in C or Java, or Perl, and doesn't even know what CVS is all about? There is no requirement for someone to know C or Java for becomming a commiter. All you need is make contributions to the project. I've seen no language requirement ( Java or English ) We have plenty of people who don't care about politics - they just don't vote or are smart enough to not participate in the flame-wars. Is it a vicious abuse to ask to free this community from a concept like meritocracy as the number of lines of code you put into CVS? I don't think so, because if this community believes that freedom is a vicious abuse, this community is racist, racist towards those who can't or don't want to have to deal with CVS, no more and no less as one could be racist on the color of your skin, or the ideas that populate your mind... Having hierarchies of 'people can only code' and 'people who lead' is not freedom. Creating a group that is 'more equal than the others' and taking away the right to vote to those we believe don't care is not freedom. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
