[JTC] latest mod_webapp stuff ?
Hi, What about mod_webapp on JTC ? Could I get the latest stuff from CVS to let me build a new mod_webapp RPM for Tomcat 4.0.1 ? - 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]
RE: jakarta-tomcat-4.0.1-src.tar.gz and GIF corruption: WAS: tar long pathnames error
Many users complain about the TC 4.0.1 RPM with the corrupted gifs and empty HTMLs () The following, dating from 10/14 is still BAD (bad gif and empty HTMLs) http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.1/src/jakar ta-tomcat-4.0.1-src.tar.gz Question, when did a new source CORRECT tarball will be available ? - 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, November 05, 2001 12:29 PM To: 'Tomcat Developers List' Subject: jakarta-tomcat-4.0.1-src.tar.gz and GIF corruption: WAS: tar long pathnames error Could we have a new jakarta-tomcat-4.0.1-src.tar.gz uploaded since the one present at apache site have the gif corrupted ? - 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]
RE: mod_webapp prevents response.flushBuffer
hi! when using mod_webapp as connector to apache, response.flushBuffer() doesn't work in current versions of tomcat. i think this is because of the packet system of the warp connector. we work with a modified version of tomcat, which sovles this problem by implementing WarpResponse.flushBuffer() and calling localstream.flush() before calling the superclass. already posted this once but did not get any response... would need to know if this has any side effects. Markus, this has been recently fixed in CVS... (Henri, yes, time for a new RPM, thankYOUU! :) :) :) :) :) ASAP, I'll make a snapshot of jtc in my home dir and do the RPM -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: jspc4 tomcat 4.01 rpm packaging problem/bug
thanks to forward more information for my RPM :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Joakim Verona [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 13, 2001 2:51 PM To: [EMAIL PROTECTED] Subject: jspc4 tomcat 4.01 rpm packaging problem/bug hello, im trying the jspc4 jsp compiler from the tc 401 rpm on linux, and im having some problems. i have been using the tc 3.2 jspc for some time, and that has worked well. first, /usr/bin/jspc4 cant find /usr/bin/jasper.sh. the script probably wants to access /usr/bin/jasper4. when i run jasper4 wit apropriate args, it seems to send the wrong args to su, perhaps because of some difference in su versions. i then try to access the script jasper4 is calling, dtomcat4, with the command jspc. this doesnt work either because dtomcat4 doesnt accept the jspc arg. then im stuck so far... hope this helps! /joakim -- 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_webapp prevents response.flushBuffer
What APR shoud I use ? I've got a snap of JTC (rigth now), but I need to get the correct APR ? PS: Good news with Apache 2.0, APR is now shared lib, and for example my Apache 2.0 RPM export it :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Pier Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 13, 2001 3:33 PM To: Tomcat Developers List Subject: Re: mod_webapp prevents response.flushBuffer On 13/11/2001 10:10 am, GOMEZ Henri [EMAIL PROTECTED] wrote: ASAP, I'll make a snapshot of jtc in my home dir and do the RPM Thanks :) Once I finish my Job Hunt I'll also probably have some time to update and tag a release... :( :( :( 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] Release Tomcat 3.2.4
+1 I've got a question about 3.2 against 3.3. Now that 3.3 is released, did 3.2 will be deprecated in favor of 3.3, since both of them support Servlet 2.2/JSP 1.1 ? Regards - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 13, 2001 3:53 PM To: [EMAIL PROTECTED] Subject: [VOTE] Release Tomcat 3.2.4 The beta for Tomcat 3.2.4 is complete. During the beta there was one minor code change to fix bug 4577. This fix does not require another beta cycle. There are currently no Bugzilla bugs open against version 3.2.x. I propose that we release the current tip of the tomcat_32 branch as Tomcat 3.2.4. With the exception of critical bugs or sercurity updates I expect this to be the last release of the tomcat_32 branch. Fixes for non-critical or non-security bugs will be addressed in Tomcat 3.3.x releases. The vote will be open for 1 week and I will tally the results at that time. The proposal must receive at leaset three +1 votes and more +1s than -1s. - Vote to release the tomcat_32 branch as Tomcat 3.2.4. [ ] +1. I agree with the proposal and I will help support the release. [ ] +0. I agree with the proposal but I will not be able to help support the release. [ ] -0. I don't agree with the proposal but I won't stop the release. [ ] -1. I disagree with the proposal and will explain my reasons. Marc Saegesser -- 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: Tomcat: Distributed Session Management revisited
Pier: Great discussion points. I really appreciate your thoughtful feedback. My comment about Tomcat caching session data does not preclude it from being stored in the remote session server. Indeed, this would be required. My thought was this, in a multi-node network if multiple contiguous requests (for the same session) are handled by the same tomcat node, then that tomcat node should not be forced to retrieve a copy of the session from the session server for each request. It only needs to go back to the session server for the session if it doesn't have a 'valid' copy. Remember that if another tomcat instance causes the session to be updated, then the server will tell all the clients to invalidate that session. This caching works when intervening requests are handled by more than one node and that do not actually update the session attributes. Notice also, in my concept, there are no delays built into the architecture (other than the natural delays caused by sending data over the network). The session server can simply respond to callers on-demand. I've discussed some time ago about this subject and adding the session stuff in the Connector, maybe webapp/warp could be tuned for this purpose. It's clear that the persistance and replication of session data is needed for HA systems, and many solves it by using the EJB backend as repository, WebSphere for example. In some case it appears also very expensive to try to add automatically this persistance (maybe something to be added to server.xml , some webapps could live without session data even, in a soft restart mode). There is also the problem of finding a fast and portable network protocol (multicast may not run on all system, Broadcast UDP need recovery code). What's the status of mod_backhand (http://www.backhand.org/) and Apache ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 4386] - webapp1.0 will not install on Redhat 7.1
Did you try my RPM ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 13, 2001 4:49 PM To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 4386] - webapp1.0 will not install on Redhat 7.1 DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4386. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4386 webapp1.0 will not install on Redhat 7.1 --- Additional Comments From [EMAIL PROTECTED] 2001-11-13 07:49 --- If you get a undefined Symbol you should check the LoadModule and AddModule line. Like these name conventions: LoadModule xx_module/usr/lib/apache/mod_xx-yy.so AddModule mod_xx.c -- 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: IIS and TC4
sorry to ask on this list as this is really a user question, but I'm not on Tomcat-User (too much noise :-) ) so I hope you'll bear with me. Sure Is there a connector available for IIS and TC4? I've searched the archives of both lists and not come up with a definitive answer. AJP13 is supported in Tomcat 4.0.1 and so you could use mod_jk. Can I use the Tomcat 3.3 IIS connector with Tomcat 4? ditto with list searches. Yes, you could use it to make Tomcat 4 and IIS work together -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk / Ajp13 config fix on heavily loaded system
what's about loadbalancing? say, we have defined local loadbalancing using 5 ajp13-worker at workers.properties, and we have at server.xml: Ajp13Connector port=8009 maxThreads=100 maxSpareThreads=50 minSpareThreads=10 / You have the 5 tomcat running on different machines ? Does this mean, we can support through the loadbalancer 100 threads or 500 threads (100 * number of workers(5) = 500)? If you have 5 Tomcat, and that each one could eat up to 100 Ajp13 threads, yes you could have 500 threads working for you, but in that case the Apache web-server will have to be set to 500 MaxClients. b.t.w, another question: when using local loadbalancing, does every worker has its own VM or are they sharing all the same VM? I didn't understand well, you could specify your configuration... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat: Distributed Session Management revisited
Costin, that point of view is really interesting. What about separating the distribution part from the integration part of a integrated solution. That would user's give the option to use the transparent session replication or to use explicit object replication services. The former would ease their live with the drawback of missing transaction support, the latter would give the app-developer all control over it. More important is separating the implementation of the 'distribution' part as a stand-alone module. I'm absolutely -1 on putting this in the same space with the main tomcat4 - it's already a huge mess and adding this much complexity is going to make things worse. May be a good candidate for jakarta-commons, since it could be used for example in Avalon. I'm not even sure that a Distributed Stuff Management is even Servlet Engine Specific, it fit more on EJB repository land. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Ajp14 and Ajp13
I'm in favor of this, since the protocol is only being extended, not really changed. However, I think that one of the extensions that should be implemented early on is a version negotiation so that the newer side can gracefully degrade in the future without having to rely on the user changing configuration settings. Yes, Henri already implemented this in the login phase - however Ajp13 doesn't support this. We should be carefull with the login phase. The distinction between post Ajp14 will be the number of callbacks supported - and login/negotiation is the essential one to diferentiate between Ajp13 and Ajp14+. Yes, but what will happen to a worker using ajp14 trying to connect (and so using md5 login phase) to a good old ajp13 server ? If the user doesn't set the login callback - we will use 'plain' ajp13. What do you mean by user setting callback ? in httpd.conf for examples ? If the user does have a login - it's clear he wants ajp14 ( or later ) and we can detect the number of callbacks supported. The distinction between ajp13, 14, ... will be in the number of callbacks - each version will have a set of callbacks ( sort of API version instead of protocol version ). Regardless of the Ajp version, we should support all previous ones up to 13. This will also minimize the amount of pain for 3.2.x users, who are unlikely to get Ajp14 ported, and also for users of 4.0 - again, support for ajp14 is likely to be available in 4.0.2 or later. They'll still be able to get most fixes, and we'll have less code to maintain. Make sense, but making ajp14 a sort of ajp13++, using the same port and same headers will put users in trouble. I'm in favor of having an ajp13/ajp14 unique Interceptor (java side), which will detect the rigth protocol by looking at msg headers. ajp13 use 0x1234 as header and 'AB' (0x4142) as trailer and I used 0x1235 for both header and trailer for ajp14. Also having separate headers will help people writing network disector for network dumper (ie ethereal). And on native camp, it should be easy since we'll could have an ajp13 callback and another one for ajp14, may be a protocol init callback which could set headers accordingly for future message sent/received. The client side should be able also to detect it speak ajp14 on an ajp13 server and fallback to ajp13 protocol -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
FW: Thread pool problem in Tomcat 3.3 in Windows NT 4.0
Just to finish with my message about Ajp13 and highly loaded servers - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Larry Isaacs [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 3:29 PM To: 'Tomcat Users List' Subject: RE: Thread pool problem in Tomcat 3.3 in Windows NT 4.0 There is a bug in ThreadPool that causes it to overwrite the settings installed by the Ajp13Connector. This is fixed in the nightly version of Tomcat 3.3.1 which can be found at: http://jakarta.apache.org/builds/jakarta-tomcat/nightly-3.3/ Cheers, Larry -Original Message- From: Raymond Lee [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 2:43 AM To: [EMAIL PROTECTED] Subject: Thread pool problem in Tomcat 3.3 in Windows NT 4.0 Hi, I have used Tomcat 3.3 with Apache 1.3.12 as my development servlet engine and I have a query about thread pool of Ajp13Connector in Tomcat 3.3. I define the following setting in server.xml and I expect there should be at least 100 threads created in startup of tomcat 3.3. Ajp13Connector address=127.0.0.1 port=8009 maxThreads=500 maxSpareThreads=200 minSpareThreads=100 pools=true/ However, I found there are only 25 threads instead of 100 threads created in the java virtual machine used by Tomcat 3.3. I browsed so many documents about Tomcat 3.3 and even many forums but I was unable to find any relevent information about this problem. In Tomcat 3.2, the way to define thread pool is different from that of Tomcat 3.3. Is the following setting valid in Tomcat 3.3? Connector className=org.apache.tomcat.service.PoolTcpConnector Parameter name=handler value=org.apache.tomcat.service.connector.Ajp12ConnectionHandler/ Parameter name=port value=8007/ Parameter name=max_threads value=150/ Parameter name=max_spare_threads value=100/ Parameter name=min_spare_threads value=50/ /Connector This setting can make the java virtual machine to create at least 50 threads. (I confirmed this with Task Manager) Does anyone know how to fix this? Thanks, Raymond Lee -- 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: TC 3.3, Production Quality
+1. Did you also rebuild the site since the http://jakarta.apache.org/tomcat/index.html still present 3.3 as beta (it's fixed in your recent commit) Regards - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Saturday, November 17, 2001 3:44 AM To: [EMAIL PROTECTED] Subject: TC 3.3, Production Quality I've noticed that on the main TC page of Jakarta site, TC 3.2.x is still listed as production quality release, although we all know that 3.3 is far superior in almost any respect. That's for Servlet API 2.2 and JSP 1.1, of course. Any objections if I change this? Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Change the order of releases mentioned on the TC web page
[X] +1. I agree with the proposal and I will help support it. [ ] +0. I agree with the proposal but I will not be able support it. [ ] -0. I don't agree with the proposal but I won't stop it. [ ] -1. I disagree with the proposal and will explain my reasons. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Portable SSL Support
Or even better, in SSLInterceptor. No need to change Request or the core - if it can be done in a module, it's better to do it this way. A la mod_ssl :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Problem compiling mod_webapp for IBM HTTP Server 1.9.19 running on AIX 4.3.3. Please help save Tomcat for a high profile project in Switzerland
May I recommand you take a look at mod_jk from jakarta-tomcat-connectors which use configure stuff to try to ease the build... All the developpment effort on tomcat connectors have now moved to J-T-C - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Aaron Bannert [mailto:[EMAIL PROTECTED]] Sent: Sunday, November 18, 2001 9:04 PM To: Tomcat Developers List Subject: Re: Problem compiling mod_webapp for IBM HTTP Server 1.9.19 running on AIX 4.3.3. Please help save Tomcat for a high profile project in Switzerland Lurking indeed... ;) On Sun, Nov 18, 2001 at 10:34:42AM -0800, Justin Erenkrantz wrote: On Sat, Nov 17, 2001 at 08:51:24PM +0100, [EMAIL PROTECTED] wrote: First of all I attempt to calmly summarize the problem and only then let my emotions get through. You're certainly not the first to be frustrated by this problem. :) My insufficient knowledge of AIX platforms prevents me from successfully compiling mod_webapp (as well mod_jk) on AIX 4.3.3 platform. Tomcat itself appears to be running flawlessly. Unfortunately due to my meager knowledge of AIX I seem to be unable to recompile neither mod_webapp nor mod_jk for the specified platform. Actually compilation worked fine in both cases. What did fail was the 'ld' linker. As far as I can judge about possible cause of failure, the linker requires a module export (.exp) file in order to be able successfully complete linking process. In this respect AIX appears to differ from Unixes, as I had no problems at all building mod_webapp mod_jk under Linux (Mandrake 8.0 Mandrake 8.1) as well as Solaris 8. The problem is aggravated by the management's desire to use IBM HTTP Server instead of plain Apache mainly due to IBM's SSL support, which is perceived to be more trustworthy and secure. Is my assumption right? If yes, is there a way I could generate that damn .exp file for mod_webapp? I could also live with mod_jk as a fallback scenario. [snip] I know that Aaron Bannert spent some time working with the IBM httpd folks (Victor, Greg, Bill, Jeff, etc.) trying to get AIX DSO support for Apache 2.0 and APR. I believe the eventual conclusion from the IBM AIX gurus in Austin was that the linker is not capable of handling external dependencies in an acceptable manner. Their recommendation was to wait for the next major release of AIX which would have a new linker. But, this isn't very helpful to you or to us httpd folks though. As of yet we have not been able to tame the beast that is the AIX linker WRT apache-2.0 and DSOs. The essential problem has to do with the mechanism used at runtime to load and dynamically link modules, and the aparent inability of the AIX linker to deal with interdependent shared objects. In the short term this really only applies to apache-2.0 and modules that automatically depend on other libraries, like how mod_webapp depends on libapr and libaprutil. The problem in this scenario is that libaprutil actually depends on symbols exported from libapr. First-order runtime linkages seem to work fine, but as soon as you hit a symbol that depends on that second library (even if they are statically linked into the same shared object) you'll get a segfault. It's entirely possible that over in httpd-2.0 we're doing something wrong, but given the number of people looking at this issue, that is becomming less and less likely. I have been informed by the management that if problem is not resolved by mid next week Tomcat will be replaced with WebSphere 3.5 Standard Edition. My first impression to this post was to suggest you contact your vendor for a solution. (My second and more emotionally based response was to suggest you change operating systems. ;) Hope that provides some insight, -aaron -- 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: Error: null cert chain
FYI, a Linux RPM of ssldump is available at : http://ftp.falsehope.com/home/gomez/ssldump/ Regards :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Eric Rescorla [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 10:53 PM To: Tomcat Developers List Subject: Re: Error: null cert chain Hai Wang [EMAIL PROTECTED] writes: I am working on SSL communication now, I have set up Tomcat to support SSL, but I got an error when I tried to make a connection to Tomcat-SSL server. My procedures are as follows: (by the way my server and client are sitting in the same Linux PC (Lisbon)) 1. create the key pair for server and client 2. request the certificates from thawte from both of them 3. import the reply certifcates to server and client keystores 4 export the server and client certficates and import them as the trusted certficates Detailed procedures, please see the end of the mail when I desable clientAuth, everything is fine, but when I turn on the clientAuth, the following erros come up. Let's start by finding out whether the client is actually performing client auth. Can you get an ssldump trace of the connection? (you can get ssldump from http://www.rtfm.com/ssldump). You'll want to use the -A and -N flags. Once we know what's happening we can try to figure out why. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] Author of SSL and TLS: Designing and Building Secure Systems http://www.rtfm.com/ -- 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]
[JTC] APACHE_CONFIG_VARS and 2.0.28
Hi to all JTCs, I'm trying to rebuild jk and webapp from JTC and notice we try to include config_vars.mk, which is awaited under $prefix/build/. Problem, it fit well for Apache 2.0 using default packaging (ie all under /usr/local/apache) but fail when we have it installed under another directory, ie /usr/lib/apache2 (see my latest RPM), to make it more FHS compatible. What could we do to have JTC works in such situation since I'm not sure we need to included config_vars.mk !!! - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED]] Sent: Monday, November 19, 2001 3:07 PM To: Tomcat Developers List Subject: Re: Default policy file for TC4 - excessive permissions Thats a good suggestion, thanks. I have made the change and committed it. Antony Bowesman wrote: The catalina.policy file gives AllPermissions to the webapp shared lib/classes directories by default. Isn't this too liberal. Shouldn't the policy file explicitly name the 3 jars with the default 4.0.1 distribution in lib. Rgds Antony -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: 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: [JTC] APACHE_CONFIG_VARS and 2.0.28 / jkant
I'm currently stucked with Apache 2.0.27/2.0.28
and the config_vars.mk used in JTC (jk/webapp).
It's still unclear if we should included it in all
make file and what to do when you install Apache 2.0 in a
FHS manner, as does my RPM, everything is broken.
All the Apache stuff assume everything under $prefix, which
is not the case in the FHS method (/var/www2/{manual, error, html, icons),
/etc/httpd2/conf/, /var/log/httpd2/, /var/run/httpd2.pid.
I've got to patch heavily apxs, apachectl and httpd.conf/ssl.conf
to make it works, but the config_vars.mk path is still constructed
from $prefix/build/config_vars.mk whereas it should be presented
by APXS with -q (ie apxs -q CONFIG_VARS.MK). I send today many
mails on Tomcat-dev (for JTC devs) and on new-httpd list
and hope some of this points will be fixed, but I'm not Apache 2.0
commiter and so could apply necessary patches ;(
BTW, build.xml for jkant will also need updates since we
assume to have include under apache.home/include and on
Linux FHS it's on /usr/include/apache or /usr/include/apache2
A patch is attached, I'll try to commit it tomorrow :)
-
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 [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 19, 2001 3:33 PM
To: Tomcat Developers List
Subject: [JTC] APACHE_CONFIG_VARS and 2.0.28
Hi to all JTCs,
I'm trying to rebuild jk and webapp from JTC and
notice we try to include config_vars.mk, which
is awaited under $prefix/build/.
Problem, it fit well for Apache 2.0 using default
packaging (ie all under /usr/local/apache) but fail
when we have it installed under another directory,
ie /usr/lib/apache2 (see my latest RPM), to make
it more FHS compatible.
What could we do to have JTC works in such situation
since I'm not sure we need to included config_vars.mk !!!
build.xml.diff
Description: Binary data
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jk_handler
En réponse à [EMAIL PROTECTED]: mod_jk provides the communication between the web server and tomcat. It does so by using a number of abstractions: jk_service: represents the request and the callbacks supported by the web server. jk_endpoint: abstracts the callbacks supported by tomcat. The communication is done by passing messages. Each side has a dispatcher that receive message and calls the right method. AJP13 supports a minimal set of callbacks - only what's required to forward the request and get the response. AJP14 adds more - authenticating the connection and a discovery mechanism allowing auto-configuration of jk. There are more callbacks that were discussed, and a number of possible optimizations and features could be added. My proposal is to abstract the callback using jk_handle ( on the C side ), AjpHandler ( Java side ). Excellent. The java side was already implemented for Ajp14 ( not perfect yet, just a start ). I would like to change the current Ajp13 connector to use the same model and callbacks ( Ajp14 is backward compatible, we now duplicate some code ). On C side, the handlers will implement a similar interface. The current object factory ( used to create workers, channels ) will also be used to register handlers. The 3 callbacks in jk_service and the discovery callback in ajp14 will implement the jk_handler interface. Right now the server adapter is implementing the jk_service interface - the change is quite small, the same methods will be used, just with a different initialization. The main benefit is that we'll be able to easily add more callbacks with minimal code changes. A second benefit will be that the code will be easier to understand, and the same abstractions will be used in both java and C side. I'm ( reasonably ) confident this change will have minimal impact on code stability. What do you think ? Very good ideas, everything which make mod_jk more modular should be included. I love the callback and abstract concept. Let's go with it, my +100 - 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]
RE: Where IS mod_webapp ??
While we're speaking of mod_webapp, could we update
the configure since IT DIDNT WORKS when you have
installed Apache 2.0.28 beta in a FHS system, ie:
/etc/httpd2/build/
/etc/httpd2/conf/
/usr/include/apache2/
/usr/lib/apache2/mod_*
/usr/lib/libapr*
/usr/sbin/httpd2
/var/www2/
I could build mod_jk under Apache 2.0, since it still
didn't use APR, but couldn't build mod_webapp.
apxs2 -q PREFIX = /etc/httpd2
and from configure.in =
dnl -
dnl APXS 2.0
dnl Note: APXS for 2.0 is broken, so we need to
dnl discover some of the values manually hoping
dnl to get the right layout.
dnl
dnl New vars: N/A
dnl Upd vars: APR_CFGFLG APR_VARFIL APR_LIBDIR APR_INCDIR
dnl -
MODULE=apache-2.0
local_prefix=`${APXS} -q PREFIX`
LIBTOOL=$local_prefix/build/libtool
APR_CFGFLG=
APR_VARFIL=${local_prefix}/lib/APRVARS
APR_LIBDIR=${local_prefix}/lib
APR_INCDIR=${local_prefix}/include
unset local_prefix
Why not just add --with-apr-lib, --with-apr-include to
help fix these problems !!!
BTW, even when I modify the configure, I get a libwebapp.a
but no libwebapp.so and so couldn't build mod_webapp.so !!!
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
-Original Message-
From: jean-frederic clere [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 22, 2001 6:44 PM
To: [EMAIL PROTECTED]
Cc: Pier Fumagalli; Martin Kraemer
Subject: Re: Where IS mod_webapp ??
Clere, Jean-Frederic wrote:
Pier Fumagalli wrote:
On 21/11/2001 10:15 pm, Gerard van Enk
[EMAIL PROTECTED] wrote:
Any comments?
I think it's a good idea to make a release.
I'm on a plane ATM, but +1 for me, J.F., would you be R.M.
for this one?
I will try. At least I can make the tarball and retest the thinks :)
I have prepared some prerelease tarballs.
I still have to tag and to retest my plaforms. And I will also
try to fix 4367
and 4930.
Please have a look at http://www.apache.org/~jfclere/ and tell
me if something
is wrong.
Cheers
Jean-frederic
Pier
--
To unsubscribe:
mailto:[EMAIL PROTECTED]
For
additional commands: mailto:[EMAIL PROTECTED]
Troubles with the list:
mailto:[EMAIL PROTECTED]
--
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]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Where IS mod_webapp ??
Sounds a good idea. --with-apr-lib and --with-apr-include
would be used to
overwrite ${local_prefix}/lib and ${local_prefix}/lib
Could you fix the configure.in for that, it will be great.
BTW, even when I modify the configure, I get a libwebapp.a
but no libwebapp.so and so couldn't build mod_webapp.so !!!
But it uses -l webapp, so it should use libwebapp.a. Could it
be that you have a
broken libtool?
I use the one from apache2 (from my Apache 2.0 RPM)
http://ftp.falsehope.com/home/gomez/apache2/
httpd2 -V
Server version: Apache/2.0.28
Server built: Nov 22 2001 23:18:49
Server's Module Magic Number: 20011002:0
Server compiled with
-D APACHE_MPM_DIR=server/mpm/threaded
-D APR_FILE_BASED_SHM
-D APR_HAS_MMAP
-D APR_HAVE_IPV6
-D APR_USE_FCNTL_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT=/etc/httpd2
-D SUEXEC_BIN=/usr/sbin/suexec2
-D DEFAULT_PIDLOG=/var/run/httpd2.pid
-D DEFAULT_SCOREBOARD=/var/run/httpd2.apache_runtime_status
-D DEFAULT_LOCKFILE=/var/run/httpd2.accept.lock
-D DEFAULT_ERRORLOG=/var/log/httpd2/error_log
-D SERVER_CONFIG_FILE=/etc/httpd2/conf/httpd2.conf
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
mod_jk / Ajp13 config fix on heavily loaded system
Hi to all, Some of you may have experienced problems on heavily loaded system with mod_jk and Tomcat 3.2/3.3 when using ajp13. As you may know, the Ajp13 connection is permanent and is created each time a WebServer task, for example an Apache child, have to forward a request to Tomcat. And in Apache server case, the child will stay alive, until the client requests load decrease, or when a child have passed 1000 requests (MaxRequestsPerChild 1000). And till the child close the connection, the Tomcat thread stay alive. By default Apache server support up to 150 childs : (MaxClients 150 in httpd.conf) But by default, the Ajp13 Interceptor won't use more than 100 threads, so you're stuck when the 101th Apache child want to forward a request and see the following infamous trace in mod_jk.log : [wed oct 31 11:03:21 2001] [jk_ajp13_worker.c (196)]: In jk_endpoint_t::connect_to_tomcat, failed errno = 111 [wed oct 31 11:03:21 2001] [jk_ajp13_worker.c (635)]: Error connecting to the Tomcat process. [wed oct 31 11:03:21 2001] [jk_ajp13_worker.c (848)]: In jk_endpoint_t::service, send_request failed in send loop 2 [wed oct 31 11:03:21 2001] [jk_ajp13_worker.c (228)]: connection_tcp_get_message: Error - jk_tcp_socket_recvfull failed [wed oct 31 11:03:21 2001] [jk_ajp13_worker.c (712)]: Error reading reply [wed oct 31 11:03:21 2001] [jk_ajp13_worker.c (845)]: In jk_endpoint_t::service, get_reply failed in send loop 0 [wed oct 31 11:03:21 2001] [jk_connect.c (143)]: jk_open_socket, connect() failed errno = 111 [wed oct 31 11:03:21 2001] [jk_ajp13_worker.c (196)]: In jk_endpoint_t::connect_to_tomcat, failed errno = 111 [wed oct 31 11:03:21 2001] [jk_ajp13_worker.c (635)]: Error connecting to the Tomcat process. In some case, Apache could be able to connect, since Tomcat listening thread will accept incoming connection, but will drop it later if it fail to give the socket to a new thread. In that case you'll see only in log : [wed oct 31 11:03:21 2001] [jk_ajp13_worker.c (848)]: In jk_endpoint_t::service, send_request failed in send loop 2 [wed oct 31 11:03:21 2001] [jk_ajp13_worker.c (228)]: connection_tcp_get_message: Error - jk_tcp_socket_recvfull failed [wed oct 31 11:03:21 2001] [jk_ajp13_worker.c (712)]: Error reading reply Fortunatly, the fix is easy, just configure Ajp13Connector in server.xml to support up to 150 threads (or whatever you define as MaxClients in Apache, didn't know how on IIS/iPlanet). Ajp13Connector port=8009 maxThreads=150 maxSpareThreads=50 minSpareThreads=10 / Also you should take care of the number of descriptors opened in your webapplication, which is : Tomcat used descriptors (sockets, files) + YouWebApp descriptors (files, sockets, jdbc...) The JVM, like any others process have a limit on the number of descriptors it could open (and of course on number of threads). So take care of closing no more used socket, files and so on. - 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]
FW: Tomcat 3.3 Document Bug
-Original Message- From: OGAWA, Motoyuki [mailto:[EMAIL PROTECTED]] Sent: Monday, November 26, 2001 2:41 PM To: [EMAIL PROTECTED] Subject: Tomcat 3.3 Document Bug Hello, My name is Ogawa, Motoyuki. I am a Java engineer in Tokyo, Japan. I found a bug in the Tomcat 3.3 document. It says: http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-apache-h owto.html When Tomcat starts up it will automatically generate a configuration file for Apache in TOMCAT_HOME/conf/jserv/tomcat-apache.conf. But I cannot find the configuration file. Tomcat 3.2 has it. I guess its description remains as the Tomcat 3.2 document. -- OGAWA, Motoyuki ([EMAIL PROTECTED]) Daiwa Institute of Research Ltd. Information Technology Center -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
FW: http://jakarta.apache.org/tomcat/tomcat-3.3-doc/index.html
-Original Message- From: James Bromberger [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 27, 2001 7:03 AM To: [EMAIL PROTECTED] Subject: http://jakarta.apache.org/tomcat/tomcat-3.3-doc/index.html Hello, I think there is a documentation bug on: http://jakarta.apache.org/tomcat/tomcat-3.3-doc/index.html This is the Tomcat 3.3 user documentation, and yet under the Using Tomcat list item is another LI entitled Tomcat and SSL. The comment beside this is using SSL with Tomcat 3.2 Should this not be 3.3? Is this document about 3.3, or 3.2? My understanding was that this page was an index for 3.3 documentation. Hope this helps, Yours, James Bromberger -- James Bromberger, Senior Web/Systems Administrator, JDV +61 8 9268 2909, +61 417 322 500 Fax: +61 8 9268 0200 JDV - e-Commerce and Outsourcing Solutions for Financial Services http://www.jdv.com/ Any securities recommendation contained in this document is unsolicited general information only. Do not act on a recommendation without first consulting your investment advisor to determine whether the recommendation is appropriate for your investment objectives, financial situation and particular needs. JDV believes that any information or advice (including any securities recommendation) contained in this document is accurate when issued. However, JDV does not warrant its accuracy or reliability. JDV, its officers, agents and employees exclude all liability whatsoever, in negligence or otherwise, for any loss or damage relating to this document to the full extent permitted by law. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk and APR
I would even use APR to build mod_jk: APR of httpd-2.0 (installed or source) otherwise the one given by --with-apr parameter with configuring mod_jk :) Ok, we should be carefull with apr, since I've got many problems using it with mod_webapp when creating library libwebapp. I wasn't able to use the libtool generated by Apache 2.0 and could only with the system libtool. The problem is that system libtool (1.3.4) on my Redhat 6.2 couldn't be used to create Apache 2.0 ???) Nota also that APR stuff is today installed under apache2 subdir in general case but when trying to adhere to FHS, it should be installed /usr/lib/ and /usr/include/apr. APR is just more Apache 2.0 sub lib, it's really a vite new piece of code, used by Apache 2.0 but which will be very usefull for server developpers wanting portable code :) (end of publicity) That's why we add --with-apr-lib and --with-apr-include I'll go ahead and create an APR directory. To keep things simple and clear I'll not touch configure - build.xml will detect if APR_INCLUDE/apr.h is present and compile the apr-dependent files. Ok. The APR code will be entirely optional for now - when we are comfortable and everything is tested we can deprecate the current platform-specific code ( or leave it in - it doesn't hurt and people who have any problem will have a fallback ) Excellent, we should give a way to user to fall back to OS calls if they could find an APR installed The actual makefiles logic is a bit too complex I think there should be more targets to remove the automaticly generated makefiles. Is there any reason we don't use GNU make ? This would allow many simplifications in the build files ( the VPATH is one clear one, we could also simplify a lot by using the many functions available in gmake ). A question for people with old make tool, no more a problem for Linux/xxBSD users. What about Solaris, AIX and HP/UX ? I would also like to have built.properties included in the Makefile - it would allow a consistent mechanism of setting preferences ( paths, etc ) ( i.e. consistent with tomcat and other jakarta projects ). Not sure how difficult it would be, but when we switch to APR we'll have no reason to use configure - everything is supposed to be portable ! Good But is it is still necesary to keep native makefiles when we have a new _nice_ tool? Yes, jkant is a great piece of code but we should keep this functionnalities. Creating native code with java ant is really new and many people will be desoriented. It's For a while, yes, it's better to have a smooth transition. And we first need to make sure everyone is comfortable with a new build system. Exact, and have jkant included in jakarta-ant :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Tomcat 4.0.2 Release Plan
What about mod_webapp SNAPSHOT for this release ? Will you include the latest stuff from JTC CVS ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 28, 2001 7:26 AM To: [EMAIL PROTECTED] Subject: [VOTE] Tomcat 4.0.2 Release Plan Hi, I think it's the appropriate time to consider starting a new release cycle for Tomcat 4.0. There has been a variety of significant bugs fixed since 4.0.1 (although there hasn't been any fixes for any showstopper bug). I don't plan to propose a formal release plan for this release, as it is a bugfix-only release, and it will be released as soon as there are no more must-fix issues remaining in the most current release candidate. - A few more code merge will happen between now and the first beta release (at least one to add JAVA_HOME support in the install script). - The release notes will document all the fixes which occured since 4.0.1. - The release notes will list the must-fix bugs. This generally includes bugs whose severity in Bugzilla is 'blocker' (P1), 'critical' (P2) or 'major' (P3). - Tomcat 4.0.2 won't have any regressions over 4.0.1. - All betas for 4.0.2 should be considered release candidates if the must-fix issues list is empty. - Tomcat 4.0.2 beta 1 should be released between 12/02 and 12/16. - This vote will run until 12/01. ballot [ ] +1: I approve this plan, and I'll help [ ] +0: I approve this plan [ ] -0: I'm against this plan, but I won't veto it [ ] -1: I'm against this plan, and my reason is: /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: [VOTE] Tomcat 4.0.2 Release Plan
There are few things I would like to see fixed before releasing: - the jvmroute ( I'll do a patch if nobody else does it ) YES PLEASE +1, will give tomcat 4.0 access to load balancing feature of mod_jk ;) - backporting the 'trusted apps having access to catalina internals' from 4.1 I would be happier to see 4.0.2 released a bit later, I hope we can freeze j-t-c/mod_jk around 12/15, but we need few weeks for testing. If 4.0.2 is released on 12/16, it needs to use a branch ( same code as in 4.0.1 ). Yes, could we wait some time and fix one of the problem of users about the webconnector ? I'm still working on packaging mod_webapp, (yes yes) against the recent Apache 2.0.28 beta -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
FW: [Cryptix-Users] OpenSSL and java keytool
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 28, 2001 11:51 AM To: GOMEZ Henri Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [Cryptix-Users] OpenSSL and java keytool I only did now. Guess my previous answer doesn't make sense. Perhaps you can check which CipherSuites your JSSE server supports? SSLServerSocket s = ... System.out.println(Enabled cipher suites:); String[] c = s.getEnabledCipherSuites(); for (int i = 0; i c.length; i++) System.out.println( + c[i]); To enable all CipherSuites: s.setEnabledCipherSuites(s.getSupportedCipherSuites()); Maybe that helps? BTW, nice document, that howto. Maybe a small suggestion: I'd also add the KeyStore type as a parameter. This way, it would be possible to use other KeyStores then JKS. And perhaps a storepass parameter as well. Stef Did you read the tomcat SSL howto ? We've discussed that there : http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-ssl-howto.html Regards - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Manfred.Zerndl [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 28, 2001 8:50 AM To: [EMAIL PROTECTED] Subject: [Cryptix-Users] OpenSSL and java keytool Hi there, So far, I have been working under Linux (SuSE 7.0) with OpenSSL 0.9.6. I used OpenSSL for creating a self-signed server certificate for a https server. Everything ist fine so far. Meanwhile we want to set up a servlet engine (Tomcat 3.2.3) which is also https-enabled. Unfortunately, tomcat administrates its certificates with keytool coming with the JDK 1.3. When I try to import my OpenSSL certificate into keytool, restart my servlet engine, I get a browser error saying that the browser (e.g. Netscape) and the server have no common encrypttion algorithms. Can anybody help me? Thanks Manfred Zerndl --- Manfred Zerndl Bezirksfinanzdirektion München Alexandrastr. 3, D-80538 München, GERMANY [EMAIL PROTECTED] For BUGS: provide Cryptix version, Java version, platform, STACK TRACE and preferrably a small stand-alone program demonstrating the problem! Subscribe/unsubscribe/change your options at: http://lists.cryptix.org/mailman/listinfo/cryptix-users/ For BUGS: provide Cryptix version, Java version, platform, STACK TRACE and preferrably a small stand-alone program demonstrating the problem! Subscribe/unsubscribe/change your options at: http://lists.cryptix.org/mailman/listinfo/cryptix-users/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] New Committer: Jazmin Jonson
+1 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk and APR
No, I am not using a Gnu make - But I will: you convince me :) Would it be ok if we make Gnu make a requirement for the build system ? There are many cool feature that would make building much easier ( patterns, globs, etc ). +1, even AS/400 has a gnu make :) After we start using APR I see very little benefit in using much configure - in fact we must make sure our code is platform independent. Ant + a simple gnumakefile should satisfy anyone's taste. What about autoconf stuff ? BTW, could you help me with a small test 'apr channel' for unix-domain sockets ? I can do the java side ( and the JNI ), but it would help a lot if an apr expert could be around :-) ( or at least a reimplementation of jk_channel_socket using apr, but that woulnd't bring anything new ). I want to test the new build system and get things started on the jni side ( most of the APR features will need jni code to be useable for connector - we need both sides of the channel ) JF is your man for that task... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: TC 3.3: For Servlets only
Maybe just 'Tom' (since 'cat' was eaten with JSP's ;-) +1 !=))) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: AJP Todo
Well seing Remy and Costin discussing and being agree on such subject make me more than happy and show that it was a good idea to exit connector code from tomcat 3.x/4.x CVS. The refactory on jk is important, but will give mod_jk more flexibility than ever. Yes, having jk as a common connector for ALL current tomcat servers, is a good idea, it will ease migration between 3.2/3.3/4.0 and even more allow a mixed use of all of them :) Many thanks again for that consensus :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 02, 2001 6:36 PM To: Tomcat Developers List Subject: Re: AJP Todo On Sat, 1 Dec 2001 [EMAIL PROTECTED] wrote: On the TODO list for AJP, there is: - Implementing jvmroute. I think I found a way to do it without accessing the Request. 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: JK versions
I will not check anything else into mod_jk until this is decided ( since my next commit is pretty big and likely to brake things, I did a lot of changes in uri_map, etc. - I need a stable branch labeled before doing the commit ). Ok, let's release mod_jk to 1.2 and start 2.0. The refactoring is massive but until it will be finished we'll need a running and working mod_jk. What we should do : - Release it (1.2) - make binaries for all knowns platform (Apache w/o SSL, IIS, iPlanet, Domino) - Create a link to this repository which could be used by both Tomcat 3.2, 3.3, 4.0 - And may be start to think about creating web pages for J-T-C -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JK versions
| - And may be start to think about creating web pages | for J-T-C A small webpage with something like download mod_jk on it would do the trick for now! Anything is better than nothing! And a link to it from the Tomcat webpages would really be something! It's IMPOSSIBLE to find things now. Really really bad.. yes, I agree ! i'll have to play with anakia and jakarta-site if nobody else is candidate ;( -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JK versions
After reading the commit log - most changes related to jk_channel, jk_registry, etc are pretty safe ( as they don't change any logic ). We could actually release Jk1.2 using the main tree - if everyone is comfortable with that. If not - Oct21 is probably a good point to branch ( the release date for 3.3 ). There are few fixes for ebcdic support and few small things that would have to be re-applied. Let's get the old version, and then I'll reapply the EBCDIC changes. We should keep ajp12 is JK 1.2 :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 5113] - tomcat4-manual-4.0.1-1 rpm missing files
Will be fixed with release 4.0.2 of rpm - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 04, 2001 11:40 AM To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 5113] - tomcat4-manual-4.0.1-1 rpm missing files DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5113. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5113 tomcat4-manual-4.0.1-1 rpm missing files --- Additional Comments From [EMAIL PROTECTED] 2001-12-04 02:40 --- when you look at the files you wil see that they are zero bytes when installed from the rpm, the files are there, but empty alas. -- 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]
JK versions status and web pages ?
What's the final status of versioning ? - jtc/jk/native mod_jk 1.2 - jtc/jk/native2mod_jk 2.0 So we could make soon a release of mod_jk 1.2. BTW: I need guidelines to create the JTC, at least jk webpages. - Did we have to choose anakia / buildsite ? - what will be the URL ? (http://jakarta.apache.org/jtc/) ? where will it be put on jakarta.apache.org ? I plan to move some of the current Tomcat 3.3 documents, ie mod_jk, IIS, part of SSL to this page. - 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 [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 04, 2001 10:12 AM To: Tomcat Developers List Subject: RE: JK versions After reading the commit log - most changes related to jk_channel, jk_registry, etc are pretty safe ( as they don't change any logic ). We could actually release Jk1.2 using the main tree - if everyone is comfortable with that. If not - Oct21 is probably a good point to branch ( the release date for 3.3 ). There are few fixes for ebcdic support and few small things that would have to be re-applied. Let's get the old version, and then I'll reapply the EBCDIC changes. We should keep ajp12 is JK 1.2 :) -- 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: Superb OSS Java IDE
on 12/4/01 8:23 AM, GOMEZ Henri [EMAIL PROTECTED] wrote: www.eclipse.org OSS version of VisualAge for Java, by the team who does VA Java :) Excellent Cool news. However, it isn't truly superb until it runs on OSX. :-) Some lobbying to be conducted ;) Important point, this IDE support CVS as repository . Trully tailored for java OSS projects. NB: It's the Visual Age for Java team who do Eclipse -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
FW: How to build mod_webapp for S390/Linux
-Original Message- From: SAMY rengasamy [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 06, 2001 7:12 PM To: GOMEZ Henri Subject: RE: How to build mod_webapp for S390/Linux A couple of days actually became a couple of weeks, sorry for the delay. Here is the link for mod_webapp.so as a zip file. http://www.tuxosaur.org/downloads/mod_webapp.zip http://www.tuxosaur.org/downloads/mod_webapp.zip Thanks, Samy Rengasamy.
RE: Jk2: pools and memory
The current code is using some 'interesting' tricks with the jk_pools -
it does some funny buffer allocations on the stack and use the buffer
to create a pool ( which itself is allocated on the stack ).
While this may have some performance benefits, the code is
extremely hard
to read, and doesn't 'map' to the new APR pool.
What I would like to do ( if nobody objects ) is to use:
struct jk_pool {
...
jk_pool_t *(*createChild)( jk_pool_t *_this, int sizeHint );
...
}
The pool_open, etc will be removed - same for the buf[] based
allocation.
why not. Frankly you love too much java :)
Given that we recycle the endpoint ( and it's pool ) - I don't
think we'll
loose too much. If APR is used we'll use apr pools anyway ( which don't
have support for the funny stack allocation ). For non-APR case, malloc
will be fine.
I'll also go ahead and replace all mallocs in the code to use the
pools.
However, I'm not an C expert ( or even a C programmer ) - if
I'm missing
something please let me know.
free must match malloc, that's all for now :=)
Question could be about recycling pools.
PS: Costin, you go too fast, I didn't recognize anything in jk2 ;)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [j-t-c] problem in ajp_process_callback (in jk_ajp_common.c)
I know it well, and take a serious look even
if it will be seriously reworked in jk2...
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
-Original Message-
From: Kevin Seguin [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 07, 2001 12:16 AM
To: Tomcat-Dev (E-mail)
Subject: [j-t-c] problem in ajp_process_callback (in jk_ajp_common.c)
in ajp_process_callback, here is the block of code that
handles sending the
next chunk of data from the webserver to tomcat:
--- snip ---
case JK_AJP13_GET_BODY_CHUNK:
{
unsigned len = (unsigned)jk_b_get_int(msg);
jk_log(l, JK_LOG_DEBUG, received
JK_AJP13_GET_BODY_CHUNK,
len=%d\n, len);
if(len AJP13_MAX_SEND_BODY_SZ) {
len = AJP13_MAX_SEND_BODY_SZ;
}
if(len ae-left_bytes_to_send) {
jk_log(l, JK_LOG_DEBUG, len
ae-left_bytes_to_send
(%d %d)\n,
len, ae-left_bytes_to_send);
len = ae-left_bytes_to_send;
}
if(len 0) {
len = 0;
}
/* the right place to add file storage for upload */
if ((len = ajp_read_into_msg_buff(ae, r, msg,
len, l)) = 0)
{
r-content_read += len;
return JK_AJP13_HAS_RESPONSE;
}
jk_log(l, JK_LOG_ERROR, Error ajp_process_callback -
ajp_read_into_msg_buff failed\n);
return JK_INTERNAL_ERROR;
}
break;
--- end snip ---
in this line:
if ((len = ajp_read_into_msg_buff(ae, r, msg,
len, l)) = 0)
{
shouldn't pmsg (the post message) be read into, not msg? i
think you only
run into this situation when the posted data doesn't fit into the first
message to tomcat, or a handling servlet doesn't make use of
content-length
and tries to read more bytes than are available. i'm not sure
though...
the code is a little hard to follow :)
I've written that piece of code some months ago but it was modified and
now I'm not sure (I feel you could be rigth). This code turned to be
a real spaghetti and should we reworked. I'll work on it as soon
as Costin will finish refactory
anyway, i was running into a problem with an infinite loop in
the ajp layer.
when i made this change, the problem went away.
can someone who knows this code better than i take a look? thanks in
advance.
I'm on it :)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Superb OSS Java IDE
Cool news. However, it isn't truly superb until it runs on OSX. Some lobbying to be conducted ;) Not even lobbying to be done, the initial native code could be ported to MacOsX :) Important point, this IDE support CVS as repository . Trully tailored for java OSS projects. It is wonderful... but the CVS integration puts everything in as binary right now :-( Could you developp ? did the cvs support is incorrect ? if so as an OSS project we'll find patches soon ;) (also looks very old on Linux) What do you mean by old on Linux ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Submission: Portable SSL Support
It compiles with or without JSSE, and runs fine without an SSL connector. However, I haven't actually gotten around to doing the whole keystore thing here, so the (big) one thing I haven't tried (yet) is to run it with an JSSE-SSL connection. Nota to interested people that PureTLS require : cryptix32-r3.2.0 (for recent JDK) cryptix-asn1 (from puretls site) which are both BSD like licence :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Vote] New committer: Eric Rescorla
As you may know, Eric Rescorla is one the few specialists in SSL in the world, author of one of the few SSL bible books and he have also created the excellent OpenSource JSSE alternative, PureTLS. He strike back in adapting PureTLS to Tomcat, today Tomcat 3.3, and so I would like to propose him as a new committer. Votes please? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RPM new packaging proposal
Hi to all, I want to propose a new packaging policy for Tomcat, 3.2/3.3/4.0 RPMs. Up to now, the Tomcat RPM which are built from the source present in jakarta site and include the binary jars present in the source tarball. To respect the general RPM packaging method (Mandrake, Redhat, Suse and others), and more generally packaging policies from Debian group, I wish to remove the use of included jar and use the jar for the other required RPM. In tomcat 3.2.x case. * servletapi3-3.2.4 will provide servlet-2.2.jar in /usr/share/java * tomcat3-3.2.4 will provide webserver.jar and jasper.jar * xml parser will be grabbed from the one found on our system and following the jpackage project, I'll make use of jaxp_parser.jar which live in /usr/share/java and which is a symlink on a real XML parser like, xerces-j (xerces.jar), crimson (crimson.jar), xml4j (xml4j.jar), all of this living in /usr/share/java. servlet.jar and xml_parser.jar won't be copied from /usr/share/java but will use symlink . ln -s /usr/share/java/servlet-2.2.jar /var/tomcat/lib/servlet.jar ln -s /usr/share/java/xml_parser.jar /var/tomcat/lib/xml_parser.jar In Tomcat 3.3 case, it will be similar expect I'll add also xalan.jar which is present in xalan-j RPM (2.1.0 today). In Tomcat 4.0 case, we'll make use also of jmx, jndi and tyrex, which all live in the respective RPM. Tomcat 4.0 will also make use of servletapi4, which provide /usr/share/java/servlet-2.3.jar JSSE is a special case, since it's not mandatory but may be installed in tomcat lib dirs if detected at install time (thanks to comment this automatic installation) As such, all the needed RPM will be provided as source and binary (noarch) in distrib directory so users will have everything necessary to use the RPM. This refactory is part of a job conducted on jpackage, http://jpackage.sourceforge.net/, which is a project to provide a full RPM distribution of usual java applications and libraries. All the major jakarta.apache.org and xml.apache.org projects are available at jpackage, making the dependencies easier to handle. Nota that jpackage make extensive use of xml, xml - spec translator, ant (building) and rpm (for packaging). Thanks to give your opinion. Regards - 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]
RE: JK2: Configuration(1)
On Fri, 7 Dec 2001, GOMEZ Henri wrote: Caution, caution with security. On many sites, the web-server is located on a DMZ so subject to be hacked, while the Tomcats are behind firewall. Having webapp (program) could raise many problems. Hmm... I hope sandboxing is used for tomcat in this case... The problem is not sandboxing but really that a web-server is often in a low-security zone and should be considered as possibly compromized. You could have the static part of a webapp there since it's a low risk of application discovery but the dynamic part, jsp/servlet/struts's/velocity's/... should be located elsewhere and ideally behind a firewall accepting only ajp communication between web-server and tomcat's. INTERNET --- FW --- APACHE HTTP - FW (only ajp13) - TOMCAT's Why not imagine that Apache will ask to Tomcat, may be to a tomcat tagged a master repository, to be send all the WEBAPPS infs ? As I said in a previous mail, startup sequence is one big problem. The idea of having one tomcat on a farm of tomcat as the master repository of webapp will even ease the deployment of application. - Put new or updated webapps in master repository - Apache discover updates or creation and update URL mapping accordingly. - Apache could then ask to the master repository to have a copy (may be a .war) of updated/created webapp - Apache then 'upload' the webapp to other tomcats. To enforce security, WEBAPP wars should be encrypted using a key known only by tomcats, that way even if the webserver is compromized, hacker couldn't decrypt the webapp. The other - I believe it's simpler. Apps must be deployed on apache as well, or at least the static content ( and with my proposal WEB-INF/jk.properties ). That's ok for me... mod_jk will use the same logic as tomcat to find all subdirs, and automatically add the contexts. ( using 'global' mappings ) Why not, I'll be more than happy to remove workers.properties and have it included in httpd.conf. Good things will be to map VirtualHost to remote Virtual on Tomcat. Well... I already added code to allow use of httpd.conf instead of workers.properties ( I use it for development, so I don't have to change 2 files ). Good, did the IIS/iPlanet port could use the same mecanism ? Virtual hosts are a problem I'm trying to resolve - the current mapper doesn't seem to have that, not sure how it works on IIS/iPlanet. Do you means that a VirtualHost entry on Apache should ask only for revelant VirtualHost webapps in tomcat ? In ajp14 the virtual host id was the key of autoconf requests. Regarding my proposal, we can either use 3.3 non-flat webapps/ ( i.e webapps/virtual.host/app ) or have a webapp dir per virtual host, specified with either JkWebapps /webapps1 whost1.com or inside a Virtual directive. - no need to have tomcat running ( or running on the server machine ) For security reason, i'd like to avoid having webapp code (servlet/jsp) on the web-server. And if tomcat is not running (locally or remotly), did there is a need to do a collect of webapp ? For servlets - you can remove them from apache if you want. For jsps - they could be removed, but ( when I'll have time... ) I want to try sending the static content of the jsp using apache. It may work or not - but I think it's worth trying, and if it works the way I expect it should have a good performance benefit. Static part handled by Apache and dynamic by tomcat, and having Apache mix the both before sending back to users ? A great performance gain... Could we discuss about a Tomcat 3.3 running as a webapp repositories manager ? Or in general a config server ? I.e. a server ( tomcatX, apache, OpenLDAP, database ) where all configs are stored and the workers get it automatically ? configs and webapps, a common place for webapps stuff. Yes, that would be nice - but I think it's more dream-level at this moment, most people have problems with configuring the simple case. Not sure it will be much difficult by using tomcat in autoconf. ajp14 added URL/webapp discovery, we should add the webapp download (tomcat-apache) and then webapp uploading (apache-tomcats) to make the dream a reality. The sofisticated ORB model you're developp in jk2 should make it more easy and we should reserve these capacity in ajp14 protocol... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.1.txt
Did you also include the requirement on Cryptix and cryptix asn ? Nota that the cryptix-asn to be used is a patched version of the 'official'. from puretls announce : == DEPENDENCIES JDK: PureTLS has been developed under JDK 1.1.8 on FreeBSD. It has been tested under JDK 1.2 on Solaris and Windows. Cryptix: Although PureTLS includes some crypto functionality (DH and DSS implementations) it depends on Cryptix for a number of algorithms (RSA, MD5, SHA-1, DES, 3DES, RC4, RC2). It would be nice if any JCE-compliant provider would work and we'll work on that for future releases, but for the moment, Cryptix is required. The issue is that key formats are not standardized and we depend on Cryptix-specific formats. The latest version of Cryptix (3.2) can be obtained at: http://www.cryptix.org/ pCryptix ASN.1 kit: PureTLS uses the Cryptix ASN.1 kit for it's certificate and key parsing. Due to version skew you need to get a modified version from http://www.rtfm.com/puretls This version is known to work. == - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, December 07, 2001 6:37 AM To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.1.txt billbarker01/12/06 21:36:39 Modified:.RELEASE-NOTES-3.3.1.txt Log: Document PureTLS support. Revision ChangesPath 1.11 +4 -1 jakarta-tomcat/RELEASE-NOTES-3.3.1.txt Index: RELEASE-NOTES-3.3.1.txt === RCS file: /home/cvs/jakarta-tomcat/RELEASE-NOTES-3.3.1.txt,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- RELEASE-NOTES-3.3.1.txt 2001/12/05 11:29:50 1.10 +++ RELEASE-NOTES-3.3.1.txt 2001/12/07 05:36:39 1.11 @@ -3,7 +3,7 @@ Release Notes = -$Id: RELEASE-NOTES-3.3.1.txt,v 1.10 2001/12/05 11:29:50 larryi Exp $ +$Id: RELEASE-NOTES-3.3.1.txt,v 1.11 2001/12/07 05:36:39 billbarker Exp $ This document describes the changes that have been made since the @@ -41,6 +41,8 @@ Moved the setting of the default *.jsp mapping so that it is now possible to entirely disable support for jsp files. + Fixed problem with jsp_precompile parameter to JSP files. + Context properties and ContextManager properties can now be set with Property ... / elements, i.e: Property name=propname value=thevalue / @@ -51,6 +53,7 @@ variable substitution to be used in Context .../Context declarations. + Added support for PureTLS as an SSL option. Server: -- 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: JK2: Configuration(1)
To clarify - this is not a replacement or an 'exclusive' mechanism. The 'ajp14' based config, where tomcat sends notifications to apache remains. Seems like I was reinventing the wheel there for a while. So AJP14 knows how configure itself from the running Tomcat... Pretty cool in my book! That was one of the important evolution of ajp14 in regard of ajp13. The problems with 'tomcat sending config info to apache' ( and why I would not make that the 'default' simple config ): 1. It requires a strict startup sequence ( tomcat before apache ). Otherwise, if tomcat is not started apache will respond '404' for what it doesn't recognize, instead of 'temporary unavailable' or 'context is down'. This can be very problematic for users ( who'll assume the url is wrong instead of try again later ). This is easily achieved (that's how I run my boxes) through the startup script when both Apache and Tomcat are on the same box. I call this thing 'was' - Web Application Server. Here is the sample (RH Linux 7.0): Pretty the same stuff in my RPM for TC 3.3 :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JK2: Configuration(1)
Seems like I was reinventing the wheel there for a while. So AJP14 knows how configure itself from the running Tomcat... Pretty cool in my book! Yes, Henri has added quite a bit of code for that. I did few changes to make the 'autoconf' usable with other workers and more 'exposed' - see jk_webapp, jk_uriEnv. As usually costin make a remarquable cleaning here :) And this will remain and will be enhanced - we want tomcat to be able to send notifications like 'webapp reload' or 'webapp down', etc. Or the reverse - apache to send this to the workers in the farm ( assuming a 'central' tomcat or after a soft restart of apache ). The major problems and why I don't think this can be the only way: - it requires tomcat to be started We could keep a copy of the latest known configuration and fall back to this one if the 'Tomcat Master Repository' is not available at start time. Which make me think that we should add some mecanism to let a tomcat announce itself when it wake up, not so easy till we have a true multithreading WebServer... - it's not very clear how it'll work for a complex case ( many workers, some apps replicated, some not ). It's hard to imagine how to do that in general, having it automated and on the wire is too much. A simple mecanism could be to for 'at best discovery' in web-server. ie in main or virtual hosts part of httpd.conf (and corresponding IIS/iPlanet) to have a : JkAutoMount * worker (which will means, grab ALL the revelant webapps for this virtualhost instance). - it's hard to 'tune'. I think we are at an early stage, where we still learn how people are using tomcat/apache. With few scripts you can do a lot - like rsync webapps/, generate 'native' configs, insert special settings. Sure... The problems with 'tomcat sending config info to apache' ( and why I would not make that the 'default' simple config ): 1. It requires a strict startup sequence ( tomcat before apache ). Otherwise, if tomcat is not started apache will respond '404' for what it doesn't recognize, instead of 'temporary unavailable' or 'context is down'. This can be very problematic for users ( who'll assume the url is wrong instead of try again later ). This is easily achieved (that's how I run my boxes) through the startup script when both Apache and Tomcat are on the same box. I call this thing 'was' - Web Application Server. Here is the sample (RH Linux 7.0): On a complex site, Apache will probably server more that java pages - and talk with more than a single tomcat. Yes, Apache talking with a farm of tomcat using load-balancing mode. But we assume that all tomcat's have the same webapps installed. Having a file-hierarchy based system can allow delegation ( change the permissions on a dir and let a group manage an application/vhosts ), etc. Things that would be hard to do if we rely only on a wire protocol ( or at least hard to do in the next 2-3 months, after we gain more experience I'm sure we can do it ) Yes, let's put jk2 to life quickly, add stuff in protocol, (to be implemented latter). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
ajp14 URI discovery and VirtualHost : WAS: [PATCH] latest mod_jk and Apache 2.0 initialization (reposting)
I am reposting that patch again - let me know if there are any
questions or
concerns.
Costin is working on a huge refactory of jk, named native2,
and in that version the jk_init is removed from child_init.
Having it in child_init was only usefull when using ajp14
to grab URIs to be handled for a VirtualHost entry.
Since this discovery will be handled at login time, it should
be removed from child_init.
Question for Apache 2.0 experts :
Did post_config run for EACH VirtualHost or only
one time ?
In negative case, what should we use to be able to get
this init available for each VirtualHost entry ?
The key of URIs discovery in ajp14 is the virtualhost,
so we must be able to built the list of URIs handled for
each VirtualHost.
VirtualHost xxx:80
JkAutomout ajp14worker (xxx is implied)
/VirtualHost
On the remote side, tomcat, there must be a VirtualHost
directive with the related webapps associated.
Some new questions here.
- How could we define webapps which could be used with all
VirtualHost on Apache side ?
ie: I want /examples webapp for all VirtualHost in Apache.
- How do we see the DEFAULT VirtualHost in Apache ? How do we
map it with Tomcat webapps ?
- What about a WebappList to be added in tomcat to be mapped later
with the requester Virtual in Apache ?
ie: in server.xml
webapplist name=webapplist1
includeexamples/include
includeROOT/include
/webapplist
webapplist name=webapplist2
includeadmin/include
/webapplist
webapplist name=webapplist3
include*/include
excludeadmin/exclude
/webapplist
in httpd.conf
JkAutomout ajp14worker webapplist1
VirtualHost xxx:443
JkAutomout ajp14worker webapplist2
/VirtualHost
VirtualHost zzz:80
JkAutomout ajp14worker webapplist3
/VirtualHost
In such case tomcat know 3 groups of webapps,
webapplist1, webapplist2 and webapplist3.
webapplist1 explicitly cover examples and ROOT.
webapplist2 explicitly cover admin.
webapplist3 told to get all existing webapps but admin.
May ease the deployement of webapps, by using carefully
the include/exclude.
Thanks to comments.
Seems like the latest j-t-c mod_jk calls initialization
(init_jk) twice -
once during post_config and then in child_init. This has a
side effect of
trying to create non existing workers and subsequently
failing. Enclosed
simple patch prevents second initialization call.
Julius
Index: mod_jk.c
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/apache-2.0/
mod_jk.c,v
retrieving revision 1.39
diff -u -r1.39 mod_jk.c
--- mod_jk.c 2001/12/04 21:38:26 1.39
+++ mod_jk.c 2001/12/05 23:56:17
@@ -1473,7 +1473,10 @@
jk_server_conf_t *conf =
(jk_server_conf_t *)ap_get_module_config(s-module_config,
jk_module);
-init_jk( pconf, conf, s );
+if(!conf-was_initialized) {
+conf-was_initialized = JK_TRUE;
+ init_jk( pconf, conf, s );
+ }
}
/** Initialize jk, using worker.properties.
--
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: Connection reset by peer
May I recommand you to switch to Tomcat 3.3, for strict 2.2/1.1 RI, which fixes quantities of problems like this ? The RI for 2.2/1.1 is Tomcat 3.3 today, just take a look at java.sun.com :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Muhammad Ali Siddiqui [mailto:[EMAIL PROTECTED]] Sent: Monday, December 10, 2001 9:02 PM To: Tomcat Developers List; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Connection reset by peer Hello, I had the same problem with tomcat in windows environment. Its just that when ever your connection between Tomcat and its client (mostly a web browser) breaks (may be due to pressing stop button in the browser or due to any other reason) it throws exception. And the exception stack trace was printed on the console. So nothing to worry about this. I am not too sure, but I guess your tomcat didn't hang due to this reason. There must be some other problem with your environment as well. Regards, Ali. - Original Message - From: Renato [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, December 10, 2001 5:26 PM Subject: Connection reset by peer Hi all, I was looking through tomcat's log ( tomcat 3.2.4 + mod_jk under Red Hat 7.2 + Sun JVM 1.3.1_01 ) and I saw a lot of messages like this: java.net.SocketException: Connection reset by peer: Connection reset by peer at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:86) at org.apache.tomcat.service.connector.TcpConnector.receiveFully (TcpConnector.java:150) at org.apache.tomcat.service.connector.TcpConnector.receive (TcpConnector.java:121) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.proc essConnection (Ajp13ConnectionHandler.ja va:146) at org.apache.tomcat.service.TcpWorkerThread.runIt (PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run (ThreadPool.java:501) at java.lang.Thread.run(Thread.java:484) After a while Tomcat starts failing to respond till it hangs completely. I've seen Sun's JVM release and already set up the 'work around' parameters for Linux. Any other hint ? Thanks Renato. -- 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: Jk2: discovery and updates
I'm getting close with jk2, there are just few more details I need to resolve ( and then test, update the other server adapters, test again, etc). One change I'm making to get the things cleaner refers to the login and discovery protocol. Instead of a RPC-style, where Apache sends a command and read the response, I would use the same 'style' as for requests, where apache sends a messages and then listen and dispatch other messages. A single message 'PING' will be used. This message will give control to tomcat ( like SEND_REQUEST does ). Tomcat can then decide what it wants - if it wants auth, it'll send LOGIN_SEED message and expect the result ( like it sends GET_CHUNK when reading post data ). Tomcat could also decide to push config data, or context status, etc. Ok, we could have a little overhead (network latency) during this init phase but it's not a big problem since it's not too common. Which make me think that in multithreaded env like Apache 2.0 we could avoid to redo the full logging and discovery each time since we may allready know the list of webapps and related URIs. The same code will also handle config/status messages comming during normal operations. Why not. This will make the code extremely simple and clear ( at least IMHO ), and we'll gain a lot of flexibility ( and that just by _removing_ code ). I'll commit the code after some more testing, I'm pretty sure it's a good idea, but I want some feedback ( especially from Henri, who wrote most of the discovery and login code ). Having a common code which will monitor for incoming message from tomcat is not a bad idea but we'll need in that case a state-machine, just to avoid handling illegal messages WebServer could be in state: a) physically connected (login to be sent) b) logically connected (login sent and granted) c) waiting for autoconf stuff (discovery request sent) d) waiting replies In multi-threaded env we could also reuse the socket to have a thread monitoring the tomcat state by sending heart-beat messages (usefull in out-process, uneeded in in-process) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2: jkctl handler
This tries to solve the 'egg and chicken' config problem, and to fix/enable some other things. I want to add a second handler in mod_jk, similar with the 'status' for apache, mod_jserv, etc. ( same security issues - i.e. users will need access control, to use it, etc ). good thing The most important feature ( for now ) will be the handling of 'ping', where mod_jk will connect to any worker it knows about and send a ping message. could you explain us more about ping ? Whenever tomcat starts, the ajp connector ( if configured to ) will access this control uri - Apache will then reconnect to it and update it's info. he he good idea, tomcat call Apache, i like it :) ( apache does try to connect to workers when it starts, but it is possible that tomcat was down ). It will also update it's up/down state for workers that were marked as down as result of connection failure. This will also alow user to add/remove application in a 'lb' environment in a nice and clean manner. The handler will report the status of it's workers as result ( in simple XHTML format, nothing fancy ). Opinions ? Votes ( I'm looking for +1s == I will help :-) Seems good, what's the help you need there ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2: jkctl handler
could you explain us more about ping ? Jk now has a 'ping' message type, which replaces the login and discovery messages. It will send the 'ping' as the first packet when it opens the connection, and also every time it is asked for ( or even periodically ). The ping will be equivalent with an empty request - it will 'switch roles', allowing tomcat to send messages and get/set information. For example, tomcat can send a 'loginSeed' packet and request md5 auth. Or it can request a different auth method. Then it can send uriMaps or contextStatus messages. What the result on login phase ? webserver send ping. tomcat send a loginseed in reply webserver send the loginsequence tomcat reply by sending log granted/deny How did tomcat will send uriMaps/ContextStatus without knowing from which VirtualHost the login came ? Did we add the VirtualHost info in login message ? The C side is very simple ( and clear - I hope ) - adding new message handlers require just adding a C file and adding it to the registry. See the processCallbacks method in workerEnv. Did the callback will have information about current state ? ie: connect stage (physical, logical (granted), autoconf received) Ping will get an 'ok' response, signaling tomcat is ok - but before the ok message tomcat can update anything else or request anything. webserver send ping. tomcat send a loginseed in reply webserver send the loginsequence tomcat reply by sending log granted/deny tomcat send ok to ping ? Opinions ? Votes ( I'm looking for +1s == I will help :-) Seems good, what's the help you need there ? Right now the most important thing is to make sure jk2 builds and works as good as ( or better than ) jk1. Then we have to port the other server connectors ( apache13, iis, etc ). I want to finish ( or at least 'freeze' ) jk2 refactoring ( or at least the first round ) in few days - but I also want to sleep, so any contribution would be great - testing, updating connectors, implementing the 'jkctl' ( or parts of it )... Ok, what about waiting for jk2 freeze, and then let us start in writing callback handlers ? May be good to prepare for us empty callback which will be implemented by contributors ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2: discovery and updates
Tomcat could also decide to push config data, or context status, etc. Ok, we could have a little overhead (network latency) during this init phase but it's not a big problem since it's not too common. Which make me think that in multithreaded env like Apache 2.0 we could avoid to redo the full logging and discovery each time since we may allready know the list of webapps and related URIs. Init happens only the first time, or when an error happens ( like tomcat was restarted and we lost the connection ). In the second case, it's possible ( even likely ) that tomcat has other settings/apps. ( XXX todo: detect webapp reload in aprconnector :-) Did there is plan to put the init stuff in shared area to avoid multithreaded web-server do the full stage of autoconf. The idea will be that each child/thread will do the login/auth phase and then check if autoconf is allready available to skip this stage. The shared data should be unique by VirtualHost in such case, since each Virtual could have it's own version of uriMaps. See my previous question about ajp14 and discovery for more comments and questions about this, particulary the DEFAULT webapps and webapplist Having a common code which will monitor for incoming message from tomcat is not a bad idea but we'll need in that case a state-machine, just to avoid handling illegal messages WebServer could be in state: a) physically connected (login to be sent) b) logically connected (login sent and granted) c) waiting for autoconf stuff (discovery request sent) d) waiting replies After the first 'ping' message tomcat has 'control' - it can send any message it wants. Apache doesn't need any state, it'll just receive messaes from tomcat and execute them. It tomcat wants md5 auth - it'll request it. If it fails - it'll send a 'notok' message that would close the endpoint. ok The state can be only maintained on tomcat side, we don't need any complexity on the C side. In that case, tomcat will be the master of connexion and so will turn Apache/IIS/iPlanet into a slave state engine ? We could have tomcat set a 'state' field in endpoint if we need to, and check it - but I think right now is not needed and would make things complex. No, but the main idea is to be sure that the handler have a minimum knowledge of the current state to have them reply accordingly. In currently known states there is no such need but we make reserve for the future. What if tomcat wants a different auth mechanism ? For a unix domain socket we probably don't need md5 auth. Sure ;) Regarding discovery, tomcat is the one that knows what changed - it should push the data. It may also use different message formats. The benefit of this logic is flexibility and simplicity. Instead of a state machine and RPC-style calls we have just messages. I agree, but I'd like to have a knowledge of state also in Apache, even if we never use it. Something to be added in protocol, maybe only one byte. Also tomcat could indicate that uriMaps is available for that Virtual by sending the corresponding uriMaps Id, which will be simply fetched by C part in any shared area... In multi-threaded env we could also reuse the socket to have a thread monitoring the tomcat state by sending heart-beat messages (usefull in out-process, uneeded in in-process) That could be handled by jkctl and ping messages. It can also be done periodically, but that can be controled by external logic. Yes and that's a question for Apache gurus, did we have a kind of watchdog task in Apache 1.3/2.0 to handle such task ? Non-multi-threaded env is more problematic, and getting all processes to update. Clear, but any tomcat sending specific HTTP request to Apache (even 1.3) could help in it, definitivly a good idea :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: org.apache.tomcat.util.net package in tomcat 3.x
+1 ( part of it has already been moved ). But if we do that, I would propose to _move_ it, not copy. Does it means that TC 3.3.1 will require and use part of J-T-C instead of keeping its own copy ? If we move more and more logic and code in j-t-c, we may need to have soon a specific jakarta-tomcat-connectors dev-list ? There is today low java in jtc, mainly native code. If all the 'ORB' java code is moved to j-t-c, for jk, next maybe warp, and coyote also, we'll need to split the current tomcat-dev list. What do you think about ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [j-t-c] patch for jakarta-tomcat-connectors/jk/native/common/jk_a jp_common.c
The patch seems valid and the pmsg was passed for this purpose in previous release of J-T-C but some folks (didn't remember who) make modifications in mod_jk part of code and the update was lost. Seems ok, you could commit :) This patch fix a real problem and should be also propagated to Tomcat 3.3.1 mod_jk go go go - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Kevin Seguin [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 13, 2001 11:20 PM To: Tomcat-Dev (E-mail) Subject: [j-t-c] patch for jakarta-tomcat-connectors/jk/native/common/jk_a jp_common.c this patch fixes a problem when posting with more than about 8K of data. it seems that when the java side of the ajp connection has to ask the webserver (jk) side for more data, it goes into an infinite loop because the next chunk of data isn't actually sent. i'm 97% sure about this patch, but since i don't know this code as well as some, i'd like someone else to review it. attached is the patch and a servlet (FileUpload.java) and a client (Upload2.java) that demonstrate the problem. the client uses HTTPClient, which can be downloaded from http://www.innovation.ch/java/HTTPClient/. incidentally, i would have used the http client in jakarta-commons, if i could have figured out how to post using an output stream :) this same test fails on the java side of ajp using the ajp stuff on the head in j-t-c/jk. again, an infinite loop. i haven't been able to figure it out yet... if somebody wants extra points ... ;) thanks, -kevin. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Configuring Multiple Tomcat JVMs with Apache - Load Balancing
there hasn't been done anything on that topic yet ? What's the status of loadbalacing, either mod_jk or mod_webapp ? Is that political due to if loadbalacing is working properly there won't be any reason to take (buy) anything else than TC ? State of the art is that today only mod_jk could handle load-balancing and only when connected to Tomcat 3.2.x or 3.3. Tomcat 4.0.x support ajp13 protocol, used in mod_jk but still miss a subtil feature (jvmroute) to be able to keep the route to the good JVM in session mode (SessionAfinity). But the current refactory of ajp protocol, under ajp14 in jakarta-tomcat-connectors, will fix somedays thanks to Costin and Kevin works :))) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: org.apache.tomcat.util.net package in tomcat 3.x
If the trafic becomes too big, we should definitely separate them, but what is big remain open ( tomcat-users is huge, I just can't read it without headaches - that's where a split will be most needed ) Exact, we'll have to split at some time just to be able to see if the question is related to core or connector land ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Configuring Multiple Tomcat JVMs with Apache - Load Balancing
Session afinity is often mandatory when in situations where parts of applications are not just data, ie when your web-application is used to discuss with a real-time system requiring that all the app session came from the same JVM. And so the session afinity must be configurable. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Monday, December 17, 2001 7:38 PM To: Tomcat Developers List; Tom Drake Subject: Re: Configuring Multiple Tomcat JVMs with Apache - Load Balancing On Mon, 17 Dec 2001, Tom Drake wrote: Keep in mind that with distributed sessions (coming soon to a tomcat near you), affinity is no longer 'required' in order to function. This provides the added benefit of fail-over. As I mentioned in a thread about this on TOMCAT-USER, there *are* session affinity requirements in the servlet specs (both 2.2 and 2.3) that should be obeyed. Craig -- 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: [j-t-c] patch for jakarta-tomcat-connectors/jk/native/common/ jk_a jp_common.c
You're right, the code is correct in tomcat 3.3 mod_jk
and conform with the latest patch I submitted in this branch.
The error was introduced in the J-T-C port
/* the right place to add file storage for upload */
if((len = read_into_msg_buff(ep, r, pmsg, l, len)) = 0) {
r-content_read += len;
return JK_AJP13_HAS_RESPONSE;
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
-Original Message-
From: Kevin Seguin [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 17, 2001 4:34 PM
To: 'Tomcat Developers List'
Subject: RE: [j-t-c] patch for
jakarta-tomcat-connectors/jk/native/common/ jk_a jp_common.c
The patch seems valid and the pmsg was passed for this
purpose in previous release of J-T-C but some folks
(didn't remember who) make modifications in mod_jk
part of code and the update was lost.
Seems ok, you could commit :)
done.
This patch fix a real problem and should be also
propagated to Tomcat 3.3.1 mod_jk
i looked at the source on the HEAD of
jakarta-tomcat/src/native/mod_jk and
didn't see a similar problem. it's quite possible that i
missed something
:)
-kevin.
--
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: Ever increasing heap size with Tomcat 3.2.3 !!!
Before my manager insists that we switch to JRun, Arg !!! can any of the Tomcat developers help with a problem of an ever increasing heap size of the Tomcat java.exe. ?? (We are running Tomcat 3.2.3 and JRE1.3.1. and the IIS redirector) May I suggest you to switch to Tomcat 3.3 instead which is faster than TC 3.2 and give you better arguments for your manager ?) We are running a load test using LoadRunner scripts on some JSP and servlets that are running under Tomcat. The load is not all that heavy but the heap size of the Tomcat java.exe process keeps growing and growing. We modified the java command line to start with -Xmx128m to allow 128 MB of heap but we still max out after a day or so. We even modified one of our servlets to create a thread that runs Runtime.gc() every 30 seconds. The LoadRunner scripts just keep logging in the same 5 people via our authentication servlet so you would think memory use would level out at some point. Tomcat 3.3 is more efficient in memory allocation and reuse which give you a more stable and less memory hog servlet engine than previous release. Nota that Tomcat 3.3 is the Reference Implementation for Servlet 2.2/JSP 1.1 Also jsp are really faster in TC 3.3 than in TC 3.2 Nothing we do seems to keep the heap size from growing. Are there known issues with Tomcat and heap size?? Doing a web search revealed numerous posts with people having similar problems so I believe there is a problem. The standard response these people receive is to increase the heap size via -Xmx But that seems like a band-aid rather than a real solution. That just delays the inevitable. Any insight as to how to keep the Tomcat process from grabbing more and more memory would be appreciated. Do you try : -Xms128 -Xmx128M ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTES] Tomcat 4.0.2 beta 1
The stuff I'd like to see added in TC 4.0.2 (release) is vmroute for supporting load-balancing via mod_jk ? What about ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 19, 2001 12:26 PM To: [EMAIL PROTECTED] Subject: [VOTES] Tomcat 4.0.2 beta 1 Hi, After some delay, I'd like to release the first beta of Tomcat 4.0.2 this week (the sooner, the better, so I plan to package the release as soon as this vote is considered approved). This release has already been approved, and although there are some issues which will need to be addressed before 4.0.2 final is released, there is no open showstopper problems. A few additional fixes may be made before beta 1 is released. The list of changes and fixes is available at: http://cvs.apache.org/viewcvs.cgi/~checkout~/jakarta-tomcat-4.0 /Attic/RELEAS E-NOTES-4.0.2-B1.txt?rev=1.1.2.4 ballot [ ] +1: Make the release [ ] -1: I'm opposed to the release until the following issues are fixed: /ballot There is also a new feature that has been added in the HEAD branch which could be worth porting: the instance pooling for STM servlets. I wrote the code as an experiment, but it appears to be working very well (I didn't notice any thread safety issues during load testing). ballot [ ] +1: Add the feature to the 4.0 branch [ ] -1: Don't add the feature, because: /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]
AJP14 work on-progress
Hi to all, I updated the CVS with preliminary code for ajp14, just for review since it's not working now. One question who how to access md5 functions under IIS/NETSCAPE ? (APR is not yet a solution :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: [VOTE] Final release of Tomcat 3.2.2
Vote to release the tomcat_32 branch as Tomcat 3.2.2. [X] +1. I agree with the proposal and I will help support the release. [ ] +0. I agree with the proposal but I will not be able to help support the release. [ ] -0. I don't agree with the proposal but I won't stop the release. [ ] -1. I disagree with the proposal and will explain my reasons. My usual RPMs (java and native for Linux) contributions. A big hi to Marc 'Just-In-Time' Release Manager :)
RE: 3.2.2 mod_jk encoding issue
Seems correct to me.
BTW, with the jakarta-tomcat-connector,
this kind of native bugs fixes will appears
outside TC 3.2/3.3/4.0 soon.
I'll correct that on mod_jk in TC 3.3 and
jakarta-tomcat-connector
To be fixed also in mod_webapp.
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
-Original Message-
From: Keith Wannamaker [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 18, 2001 10:10 PM
To: [EMAIL PROTECTED]
Subject: 3.2.2 mod_jk encoding issue
The 2.2 servlet spec errata says the uri from
HttpServletRequest.getRequestURI() should remain encoded.
[http://java.sun.com/products/servlet/errata_042700.html]
Tomcat 3.2 standalone handles this correctly, but the
mod_jk connector does not.
The connector uses the decoded uri from Apache (r-uri).
I believe the correct value to return is the raw, encoded
url (r-unparsed_uri), stripped of the query string, per
the servlet javadoc.
[http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet
/http/HttpSer
vletRequest.html#getRequestURI()]
Of course I will defer to the RM's judgement, but I'd like
to commit the following patch to the 3.2 branch prior to
next Friday:
===
RCS file:
/home/cvs/jakarta-tomcat/src/native/apache1.3/Attic/mod_jk.c,v
retrieving revision 1.7.2.3
diff -u -r1.7.2.3 mod_jk.c
--- mod_jk.c2001/02/17 05:24:00 1.7.2.3
+++ mod_jk.c2001/05/18 21:05:16
@@ -358,7 +358,13 @@
s-method = (char *)r-method;
s-content_length = get_content_length(r);
s-query_string = r-args;
-s-req_uri = r-uri;
+s-req_uri = r-unparsed_uri;
+if (s-req_uri != NULL) {
+ char *query_str = strchr(s-req_uri, '?');
+ if (query_str != NULL) {
+ *query_str = 0;
+ }
+}
s-is_ssl = JK_FALSE;
s-ssl_cert = NULL;
Ditto for /home/cvs/jakarta-tomcat/src/native/apache2.0/Attic/mod_jk.c
Comments?
Keith
RE: 3.2.2 mod_jk encoding issue
Resin 1.2.5 and 2.0b2 also use uri instead of unparsed_uri.
So what ?
-
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 [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 18, 2001 11:27 PM
To: [EMAIL PROTECTED]
Subject: RE: 3.2.2 mod_jk encoding issue
Seems correct to me.
BTW, with the jakarta-tomcat-connector,
this kind of native bugs fixes will appears
outside TC 3.2/3.3/4.0 soon.
I'll correct that on mod_jk in TC 3.3 and
jakarta-tomcat-connector
To be fixed also in mod_webapp.
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
-Original Message-
From: Keith Wannamaker [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 18, 2001 10:10 PM
To: [EMAIL PROTECTED]
Subject: 3.2.2 mod_jk encoding issue
The 2.2 servlet spec errata says the uri from
HttpServletRequest.getRequestURI() should remain encoded.
[http://java.sun.com/products/servlet/errata_042700.html]
Tomcat 3.2 standalone handles this correctly, but the
mod_jk connector does not.
The connector uses the decoded uri from Apache (r-uri).
I believe the correct value to return is the raw, encoded
url (r-unparsed_uri), stripped of the query string, per
the servlet javadoc.
[http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet
/http/HttpSer
vletRequest.html#getRequestURI()]
Of course I will defer to the RM's judgement, but I'd like
to commit the following patch to the 3.2 branch prior to
next Friday:
===
RCS file:
/home/cvs/jakarta-tomcat/src/native/apache1.3/Attic/mod_jk.c,v
retrieving revision 1.7.2.3
diff -u -r1.7.2.3 mod_jk.c
--- mod_jk.c2001/02/17 05:24:00 1.7.2.3
+++ mod_jk.c2001/05/18 21:05:16
@@ -358,7 +358,13 @@
s-method = (char *)r-method;
s-content_length = get_content_length(r);
s-query_string = r-args;
-s-req_uri = r-uri;
+s-req_uri = r-unparsed_uri;
+if (s-req_uri != NULL) {
+ char *query_str = strchr(s-req_uri, '?');
+ if (query_str != NULL) {
+ *query_str = 0;
+ }
+}
s-is_ssl = JK_FALSE;
s-ssl_cert = NULL;
Ditto for /home/cvs/jakarta-tomcat/src/native/apache2.0/Attic/mod_jk.c
Comments?
Keith
RE: 3.2.2 mod_jk encoding issue
I just tried this and verified the orginal bug and that the proposed patch does fix the problem. I'm OK with committing to the tomcat_32 branch. DOES ANYONE ELSE OUT THERE HAVE ANYTHING THEY WANT TO TELL ME? Resin would not appear to be compliant with the specification. The 4/27/00 errata indicates that getRequestURI() should return the encoded value. I was fair-play and indicate them the mistake ... :))
RE: [ANNOUNCEMENT] Tomcat 3.3 Milestone 3
The RPM are available with a new package, tomcat-webapps which hold ADMIN, ROOT and EXAMPLES webapps as requested by many on the user list :) Also a big hi to Larry for this release :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: Problems with APR under Linux...
May I recommand you Pier, try another Redhat release than the 7.1. It's a new release and for example I've got problems building latest Apache 2.0 under RH 7.1. Better test with Redhat 6.2 which is very stable and known. Regards - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 19, 2001 2:58 AM To: Greg Stein; Cc: [EMAIL PROTECTED] Subject: Re: Problems with APR under Linux... Greg Stein at [EMAIL PROTECTED] wrote: Right. Adding -lpthread manually is absolutely the wrong thing for your app to do. That was poor advice. APR generates a shell script called APRVARS. That should have everything that you need for compiling your app, and for linking your app to APR and its dependent libraries. Note: it is best to compile your app with the flags from APRVARS so that you don't get skewed compile options between APR and your app. Yes, there are well-defined binary interfaces, but heck: APR figured it all out for you, so go ahead and use it :-) You're the man :) :) Thanks a lot, will dig into that tomorrow morning... Pier
RE: upload data corruption report
Hi DAK, I tested the server/client with 'b' and without and didn't have any problems with Tomcat 3.3-m3 (with ajp13) Could try this distro also ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: DAK [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 20, 2001 6:24 AM To: [EMAIL PROTECTED] Subject: upload data corruption report I've been asked to provide more information, so here is combination of the two messages I posted with some more commentary and attachments. It pertains to Tomcat-3.2.1 and looks to be the same in 3.2.2.b4. I'm running Apache 1.3.17 on Win 2K Professional. I'm also using mod_jk I have some client code that sends a jar file to the servlet. The jar file was getting corrupted. After much digging, I found a CVS commit to Ajp13ConnectorRequest.java that mentioned a problem like this with the doRead() method. It turns out the the same applies to the doRead(byte[], int, int) method. The same problem exists in the Ajp12ConnectionHandler for that byte array read. Single byte reads for both protocols work just fine. I'm including the diffs for these classes to show what I'm talking about. I finally got out from under some work and was able to make some test code. I'm attaching the client and servlet code. The code transfers a couple parameters, then a binary file (I was using a .jar). If you call the client with BinTestClient localhost something.jar b, it uses byte-by-byte read on the server to spool the file to a temp file. If you call the client without the 'b', it uses the byte-array read that I was complaining about. Transfer a file, then try jar tvf test.jar to see if it works. I uses a jar that contains .jpg images and when using the byte array read method, it creats a corrupt jar file. If I apply my fix to the Ajp13ConnectorRequest class, it works fine. (I tried a jar that contained class files and it worked anyway...) I'd like for someone else to try this out to make sure I didn't screw something up. The code seems pretty simple. I discovered this when using JarIn/OutputStream to transfer data from client to servlet.I've seen this type of thing in Java before when writing code that talks to hardware (such as touchscreen driver and scanner drivers). David
RE: Tomcat Interceptors - proof read, anyone?
Excellent, Please switch from GPL to Apache... - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
AJP14 - updated doc
Find attached the latest revision of AJP14. Thanks to comments since the work on ajp14 is still in progress and many code will be commited next week, all for handling AJP14 ... Regards - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 /*** * Description: Proposal for Apache JServ 1.4 * * Author: Henri Gomez [EMAIL PROTECTED] * * Version: $Revision: 1.3 $ * ***/ This document is a proposal of evolution of the current Apache JServ Protocol version 1.3, also known as ajp13. I'll not cover here the full protocol but only the add-on from ajp13. This pass include comments from the tomcat-dev list and misses discovered during developpment. Missing features in AJP13 - ajp13 is a good protocol to link a servlet engine like tomcat to a web server like Apache: * use persistants connections to avoid reconnect time at each request * encode many http commands to reduce stream size * send to servlet engine many info from web server (like SSL certs) But ajp13 lacks support for : * security between web server and servlet engine. Anybody can connect to an ajp13 port (no login mecanism used) You could connect, for example with telnet, and keep the remote thread up by not sending any data (no timeout in connection) * context information passed from servlet engine to web server. Part of the configuration of mod_jk, the web server connector, is to indicate to the web server which URI to handle. The mod_jk JkMount directive, told to web server which URI must be forwarded to servlet engine. A servlet engine allready knows which URI it handle and TC 3.3 is allready capable to generate a config file for mod_jk from the list of available contexts. * state update of contexts from servlet engine to web server. Big site with farm of Tomcat, like ISP and virtuals hosters, may need to stop a context for admin purposes. In that case the front web server must know that the context is currently down, to eventually relay the request to another Tomcat * verify state of connection before sending request. Actually mod_jk send the request to the servlet engine and next wait for the answer. But one of the beauty of the socket API, is you that you could write() to a closed connection without any error reporting, but a read() to a closed connection return you the error code. AJP14 add-ons to AJP13 -- Let's descrive here the features and add-on that will be added to AJP13, which will became AJP14. Since this document is a proposal, a resonable level of chaos must be expected at start. Be sure that discussion on tomcat list will help clarify points, add features but the current list seems to be a 'minimun vital' * Advanced login features at connect time * Basic authorisation system, where a shared secret key is present in web server and servlet engine. * Basic protocol negociation, just to be sure that if functionnalities are added to AJP14 in the future, current implementations will still works. * Clean handling of 'Unknown packets' * Extended env vars passed from web-server to servlet engine. Advanced login -- 1) WEB-SERVER send LOGIN INIT CMD + NEGOCIATION DATA + WEB SERVER INFO 2) TOMCAT respond with LOGIN SEED CMD + RANDOM DATA 3) WEB-SERVER calculted the MD5 of RANDOM DATA+SECRET DATA 4) WEB-SERVER send LOGIN COMP CMD + MD5 (SECRET DATA + RANDOM DATA) 5) TOMCAT respond with LOGIN STATUS CMD + NEGOCIED DATA + SERVLET ENGINE INFO To prevent DOS attack, the servlet engine will wait the LOGIN CMD only 15/30 seconds and reports the timeout exception for admins investigation. The login command will contains basic protocol negociation information like compressing ability, crypto, context info (at start up), context update at run-time (up/down), level of SSL env vars, AJP protocol supported (AJP14/AJP15/AJP16...) The Web server info will contain web server info and connector name (ie Apache 1.3.19 + mod_ssl 2.8.2 + mod_jk 3.3 + mod_perl 1.25). The servlet engine will mask the negociation mask with it's own mask (what it can do) and return it when loggin is accepted. This will help having a basic ajp14 implementation on a web-server working with a more advanced ajp14 on the servlet engine side or vice-versa. AJP13 was designed to be small and fast and so many SSL informations present in the web-server are not forwarded to the servlet engine. We add here four negociations flags to provide more informations on client SSL data (certs), server SSL datas , crypto used, and misc datas (timeout...).
RE: about warp protocol
Better to write a disector for Ethereal :) www.ethereal.com May be something to do also for ajp12/13/14 ?) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 22, 2001 10:45 PM To: [EMAIL PROTECTED]; egcs12md Subject: Re: about warp protocol I'm writing a WARP debugger... Hold on :) :) :) Pier egcs12md at [EMAIL PROTECTED] wrote: Hi, I find MOD_WEBAPP in Tomcat 4.0b5 can't accord with src\connectors\docs\warp.html, and Tomcat-Apache frozen at http GET. this is data transfer from start up: *** httpd send 14 bytes at 2001-05-21 18:47:11.391 : 00 00 00 00 00 08 00 04 65 67 63 73 00 50 egcs.P jspd send 6 bytes at 2001-05-21 18:47:11.431 : 00 00 00 01 00 02 .. jspd send 2 bytes at 2001-05-21 18:47:11.431 : 00 00 .. httpd send 2 bytes at 2001-05-21 18:47:11.431 : 00 00 .. httpd send 2 bytes at 2001-05-21 18:47:11.431 : 00 02 .. httpd send 24 bytes at 2001-05-21 18:47:11.441 : 00 16 00 00 00 07 6d 61 6e 61 67 65 72 00 09 2f ..manager../ 0010 : 6d 61 6e 61 67 65 72 2f manager/ jspd send 6 bytes at 2001-05-21 18:47:11.441 : 00 00 00 03 00 02 .. jspd send 2 bytes at 2001-05-21 18:47:11.441 : 00 02 .. httpd send 2 bytes at 2001-05-21 18:47:11.441 : 00 00 .. httpd send 12 bytes at 2001-05-21 18:47:11.441 : 00 00 00 08 00 04 65 67 63 73 00 50 ..egcs.P jspd send 6 bytes at 2001-05-21 18:47:11.451 : 00 00 00 01 00 02 .. jspd send 2 bytes at 2001-05-21 18:47:11.451 : 00 00 .. httpd send 2 bytes at 2001-05-21 18:47:11.451 : 00 00 .. httpd send 24 bytes at 2001-05-21 18:47:11.451 : 00 02 00 14 00 00 00 06 77 65 62 64 61 76 00 08 webdav.. 0010 : 2f 77 65 62 64 61 76 2f /webdav/ jspd send 6 bytes at 2001-05-21 18:47:11.451 : 00 00 00 03 00 02 .. jspd send 2 bytes at 2001-05-21 18:47:11.461 : 00 03 .. httpd send 2 bytes at 2001-05-21 18:47:11.461 : 00 00 .. httpd send 12 bytes at 2001-05-21 18:47:11.461 : 00 00 00 08 00 04 65 67 63 73 00 50 ..egcs.P jspd send 6 bytes at 2001-05-21 18:47:11.461 : 00 00 00 01 00 02 .. jspd send 2 bytes at 2001-05-21 18:47:11.461 : 00 00 .. httpd send 2 bytes at 2001-05-21 18:47:11.461 : 00 00 .. httpd send 20 bytes at 2001-05-21 18:47:11.461 : 00 02 00 10 00 00 00 04 61 70 70 32 00 06 2f 61 app2../a 0010 : 70 70 32 2f pp2/ jspd send 6 bytes at 2001-05-21 18:47:11.471 : 00 00 00 03 00 02 .. httpd send 2 bytes at 2001-05-21 18:47:11.471 : 00 00 .. jspd send 2 bytes at 2001-05-21 18:47:11.471 : 00 01 .. httpd send 12 bytes at 2001-05-21 18:47:11.471 : 00 00 00 08 00 04 65 67 63 73 00 50 ..egcs.P jspd send 6 bytes at 2001-05-21 18:47:11.481 : 00 00 00 01 00 02 .. jspd send 2 bytes at 2001-05-21 18:47:11.481 : 00 00 .. httpd send 2 bytes at 2001-05-21 18:47:11.481 : 00 00 .. httpd send 18 bytes at 2001-05-21 18:47:11.481 : 00 02 00 0e 00 00 00 03 61 70 70 00 05 2f 61 70 app../ap 0010 : 70 2f p/ jspd send 6 bytes at 2001-05-21 18:47:11.602 : 00 00 00 03 00 02 .. jspd send 2 bytes at 2001-05-21 18:47:11.602 : 00 00 .. httpd send 2 bytes at 2001-05-21 18:47:22.848 : 00 00 .. httpd send 2 bytes at 2001-05-21 18:47:22.848 : 00 04
RE: Vacation
The buffers do belong to jakarta-tomcat-connectors/util, and in a perfect world we wouldn't have them duplicated - 3.3 should only use what's in connectors. I wouldn't mind making tomcat-connectors/util the master source for the buffer stuff, but it needs some changes in the build scripts. I'm not sure how other people would feel about this - we are very close to 3.3beta. it would be great to have the buffer code in one place, but, i've never really been comfortable with jakarta-tomcat-connectors/util being that place. it would make more sense to me to have something like jakarta-tomcat-util, where common utility code like the buffers stuff could live. jtc should be just for connectors. +1 and again why not a jakarta-tomcat-commons ? if people don't want a whole new module for utility code, then i suppose jtc is the next best place... -kevin.
RE: cvs commit:jakarta-tomcat/src/share/org/apache/tomcat/util/buf DateTool.java
It has all to do with standards. Tabs have been used for indentation for at least the last 15 years ( that's when I started playing with computers- and the tab was there ). But the point is that we're using SPACES... Since _EVER_... Discussion closed. I really doubt you guys have been using spaces everywhere since JServ. Look at Craig's source for JServ 2 (err, I mean, Catalina) : there are tabs everywhere ;) Frankly, I don't think we should make a big deal of the whole issue. Space Wars - Vi Strike Back ?)
RE: connector status in tomcat 4
My question is what the status is on the apache connector in tomcat 4. I've been testing Jakarta 4 in standalone mode and is very pleased with it, but we can't run it like that once we release the system for all our students.. ;) There is actually 2 connectors for Apache Tomcat 4.0 : - warp/webapp : Developped specifically for TC 4.0 have autoconfig stuff but lack load-balancing or IIS/NES support - ajp13/jk : Available since TC 3.2, works with TC 3.3 and now with 4.0 (thanks to Kevin). Miss the autoconfig stuff (will came in ajp14) but have load-balancing and IIS/NES support. Your contribution must match your need !)
RE: connector status in tomcat 4
I thought the idea of warp/webapp was that it was to support servlet api 2.3 and ajp/jk couldn't eaily be modified to support the new specs. What's the supposed features in 2.3 that ajp/jk couldn't support ? At least there will be in ajp14/jk the autoconfig (ie list of URL/URI handled ) = /examples/servlet/* /examples/*.jsp /examples/*.xml Dave [EMAIL PROTECTED] From: kevin seguin [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: connector status in tomcat 4 Date: Mon, 28 May 2001 09:52:43 -0500 Ok, so which one would you say should has highest priority? that probably depends on who you ask ;-) Having a quick look at the CVS repository I see jakarta-tomcat-connectors, which contains the jk-park, and in jakarta-tomcat I see the warp/webapp. Is this right? Won't ajp13/jk be included in tc4? Is it going to be replaced by warp/webapp? jakarta-tomcat-connectors (jtc) is a new module where connectors like ajp, warp/webapp, etc. should live. the idea is that the core parts of connectors should be container-agnostic. only the request/response adapters should know about containers. ajp/jk will not be included in tc4, but it will support tc4 -- there will be (is) an ajp13 connector for tc 4 (it's is a work in progress). going forward, ajp connectors for tc 3, tc 4, and maybe other containers will live in jtc. warp/webapp will not replace ajp/jk, but it will give you another choice. you'll be free to make the decision yourself as to what connector you want to use. // Erik -Original Message- From: kevin seguin [mailto:[EMAIL PROTECTED]] Sent: Monday, May 28, 2001 3:05 PM To: [EMAIL PROTECTED] Subject: Re: connector status in tomcat 4 GOMEZ Henri wrote: My question is what the status is on the apache connector in tomcat 4. I've been testing Jakarta 4 in standalone mode and is very pleased with it, but we can't run it like that once we release the system for all our students.. ;) There is actually 2 connectors for Apache Tomcat 4.0 : - warp/webapp : Developped specifically for TC 4.0 have autoconfig stuff but lack load-balancing or IIS/NES support - ajp13/jk : Available since TC 3.2, works with TC 3.3 and now with 4.0 (thanks to Kevin). Miss the autoconfig stuff (will came in ajp14) but have load-balancing and IIS/NES support. er... the load-balancing doesn't work yet for tc 4 -- the java side of it hasn't been done yet. it shouldn't be too hard to do though :) i think it's just a matter of figuring out what to do with jvmRoute on the java side (set a cookie??). Your contribution must match your need !) ___ __ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
RE: connector status in tomcat 4
In that case, what is the point of warp. Is it going to be faster, more scalable or something? warp is a whole new developpement using very recent lib tools like APR. If not why was it created? That's a good question and who has the answer ? Dave [EMAIL PROTECTED] From: GOMEZ Henri [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: connector status in tomcat 4 Date: Mon, 28 May 2001 17:43:41 +0200 I thought the idea of warp/webapp was that it was to support servlet api 2.3 and ajp/jk couldn't eaily be modified to support the new specs. What's the supposed features in 2.3 that ajp/jk couldn't support ? At least there will be in ajp14/jk the autoconfig (ie list of URL/URI handled ) = /examples/servlet/* /examples/*.jsp /examples/*.xml Dave [EMAIL PROTECTED] From: kevin seguin [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: connector status in tomcat 4 Date: Mon, 28 May 2001 09:52:43 -0500 Ok, so which one would you say should has highest priority? that probably depends on who you ask ;-) Having a quick look at the CVS repository I see jakarta-tomcat-connectors, which contains the jk-park, and in jakarta-tomcat I see the warp/webapp. Is this right? Won't ajp13/jk be included in tc4? Is it going to be replaced by warp/webapp? jakarta-tomcat-connectors (jtc) is a new module where connectors like ajp, warp/webapp, etc. should live. the idea is that the core parts of connectors should be container-agnostic. only the request/response adapters should know about containers. ajp/jk will not be included in tc4, but it will support tc4 -- there will be (is) an ajp13 connector for tc 4 (it's is a work in progress). going forward, ajp connectors for tc 3, tc 4, and maybe other containers will live in jtc. warp/webapp will not replace ajp/jk, but it will give you another choice. you'll be free to make the decision yourself as to what connector you want to use. // Erik -Original Message- From: kevin seguin [mailto:[EMAIL PROTECTED]] Sent: Monday, May 28, 2001 3:05 PM To: [EMAIL PROTECTED] Subject: Re: connector status in tomcat 4 GOMEZ Henri wrote: My question is what the status is on the apache connector in tomcat 4. I've been testing Jakarta 4 in standalone mode and is very pleased with it, but we can't run it like that once we release the system for all our students.. ;) There is actually 2 connectors for Apache Tomcat 4.0 : - warp/webapp : Developped specifically for TC 4.0 have autoconfig stuff but lack load-balancing or IIS/NES support - ajp13/jk : Available since TC 3.2, works with TC 3.3 and now with 4.0 (thanks to Kevin). Miss the autoconfig stuff (will came in ajp14) but have load-balancing and IIS/NES support. er... the load-balancing doesn't work yet for tc 4 -- the java side of it hasn't been done yet. it shouldn't be too hard to do though :) i think it's just a matter of figuring out what to do with jvmRoute on the java side (set a cookie??). Your contribution must match your need !) ___ __ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. ___ __ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
RE: [PATCH] for mod_jk/ajp13 memory leaks.
I found some more memory leaks in mod_jk. The biggest one is in mod_jk.c when there is a virtual host section in httpd.conf. Multiple conf structures are allocated, but only one was being cleaned up. Another leak was in jk_ajp13_worker.c. We were calling jk_open_pool on the endpoint object and never calling jk_close_pool when the endpoint was shut down. The attached diff files are against the latest tomcat_33 branch. If anyone is interested, I'd be happy to provide the same diffs for tomcat_32 and the tomcat-jakarta-connectors project. I'd also be happy to enter a bug if necessary. Thanks for these very important fixes. I'll commit then to TC 3.3 and JTC (which came from TC 3.3 CVS). I think Marc Saegesser will be interest in fixes for tomcat_32. Regards
RE: connector status in tomcat 4
Ok, another question then. Please, What is it that the connector has to be able to do? Is it sufficient if it simply can forward the HTTP request to tomcat or does it need to play around with it? I guess it must do something or the disscusion on ajp13/jk and warp/webapp wouldn't be. The web-server connector forward request to tomcat and add some information, like the SESSION-COOKIES. In return the tomcat add a var, jvmroute, which is used in load-balancing config to be sure that the same tomcat will serve the next queries for that session. The connector use a simple protocol, ajp12/13/14, to forward the request. You may imagine a web-connector forwarding the request using HTTP protocol, but this one is more complex to handle. // Erik -Original Message- From: kevin seguin [mailto:[EMAIL PROTECTED]] Sent: Monday, May 28, 2001 5:47 PM To: [EMAIL PROTECTED] Subject: Re: connector status in tomcat 4 for example, in my case, currently all i care about is being able to forward requests based on uri from iis and netscape to tomcat. so, for me, ajp does what i need it to, while warp/webapp currently does not (no iis/netscape support yet). hence, i would pick ajp. now, i'm not saying one is better than the other. i'm just saying that one might be better than the other in certain circumstances, and now you have a choice.
RE: connector status in tomcat 4
GOMEZ Henri at [EMAIL PROTECTED] wrote: In that case, what is the point of warp. Is it going to be faster, more scalable or something? warp is a whole new developpement using very recent lib tools like APR. And a bunch of other features and improvements, but it seems that no one ever listen to what I write - technically speaking :) :) :) :) What's the technicals improvements apart of the use of APR, technically speaking ? If not why was it created? That's a good question and who has the answer ? I do, and the mailing list archive... Check out for subjects like WARP :) The first time we saw something about Warp is in the announcement of Tomcat 4.0 m4. I couldn't find any discussion on tomcat-dev (or tomcat-user) about starting a new connector (mod_webapp) instead adding features to ajp13 and using mod_jk ;( Could help me find the initial thread on mod_webapp/warp ?) Regards = List: tomcat-dev Subject: Tomcat 4.0 Milestone 4 From: Craig R. McClanahan [EMAIL PROTECTED] Date: 2000-11-01 0:09:41 [Download message RAW] Hey folks, I'm planning on cutting a fourth milestone of Tomcat 4.0 tomorrow (Wednesday) evening. This milestone will reflect all of the changes that occurred in the servlet 2.3 and JSP 1.2 specifications between public draft and proposed final draft (and there were a *bunch* of them), completion of the remaining new 2.3/1.2 functionality, and several bug fixes. This will be the last big push of spec-related functionality additions for Tomcat 4.0. Now, we can turn our attention more towards bug fixes and performance tuning. You can help in that process by downloading and playing with the Tomcat 4.0 milestone. I'd like to see us shake it out enough to be production quality by Christmas time. Besides bug fixing and tuning, I know of several pieces of functionality yet to be added that are being worked on, including: * Web connectors (using a new connector protocol called mod_warp that is aware of webapp configuration settings, so you will not have to configure things twice). * JNDI context support (like that used in J2EE servers) for the env-entry and resource-ref configuration parameters in the deployment descriptor. If you are interested in contributing to Tomcat 4.0, there is a wish list document in file catalina/STATUS.html in the jakarta-tomcat-4.0 source tree. Feel free to propose new ideas, or to volunteer to work on one of these. Craig McClanahan =
RE: connector status in tomcat 4
Ok. Is there any written specification för the ajp protocol adn where can I find it? You could find both ajp13 and ajp14 protocol documentation in at least : jakarta-tomcat-connectors/jk/src/doc/
RE: compiling mod_jk in IRIX, bug+fix
Fixed in TC 3.3 CVS and JTC - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 1:19 PM To: [EMAIL PROTECTED] Subject: compiling mod_jk in IRIX, bug+fix Sorry if this is the wrong list and/or this is wellknown. If you want to compile mod_jk from tomcat.3.2.2 in IRIX 6.5.x, then some smallish stuff needs to be changed: in dir jakarta-tomcat-3.2.2-src/src/native/jk edit the following files in the following way: jk_sockbuf.c. replace //comment with /* comment */ jk_util.c replace //comment with /* comment */ jjk_worker_list.h add a newline at the eof. then compile and be happy! Regards, Christer Enkvist
RE: [ANNOUNCEMENT] Domino / Tomcat connecter available
We could add it to jakarta-tomcat-connector ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Andy Armstrong [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 1:05 PM To: Tomcat Dev Subject: [ANNOUNCEMENT] Domino / Tomcat connecter available I've written a Tomcat for Lotus Domino in the spirit of the IIS and Netscape connectors making it possible to use Tomcat as Domino's servlet container. It can be found at http://free.tagish.net/domino-tomcat/index.jsp It's quite small and wouldn't look at all out of place in the Tomcat release ;-) -- Andy Armstrong, Tagish
RE: [ANNOUNCEMENT] Domino / Tomcat connecter available
I'll take a look at it late and see how to include in JTC !) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Andy Armstrong [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 31, 2001 10:28 AM To: [EMAIL PROTECTED] Subject: Re: [ANNOUNCEMENT] Domino / Tomcat connecter available That would be super cool with me ;-) GOMEZ Henri wrote: We could add it to jakarta-tomcat-connector ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Andy Armstrong [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 1:05 PM To: Tomcat Dev Subject: [ANNOUNCEMENT] Domino / Tomcat connecter available I've written a Tomcat for Lotus Domino in the spirit of the IIS and Netscape connectors making it possible to use Tomcat as Domino's servlet container. It can be found at http://free.tagish.net/domino-tomcat/index.jsp It's quite small and wouldn't look at all out of place in the Tomcat release ;-) -- Andy Armstrong, Tagish -- Andy Armstrong, Tagish
RE: configure for jakarta-tomcat-connectors
Hi, I have added support for static linking of mod_jk (for Apache-1.3.x). I have used automake to reach it, it has side effects I would like to comment: - apxs cannot be used build mod_jk.so. - It needs autoconf/automake for prepare the *.in file. (Only for develloppers). - It needs libtools. I am quite unhappy about not beeing able to use apxs to build mod_jk.so, but I have not find a clean solution. Has someone an idea? What about a dual strategy ? DSO using current autoconf stuff and STATIC the new one ?
[VOTE] New Committer: Mike Anderson
I would like to propose Mike Anderson as a new committer. He found many subtils bugs in mod_jk and since he's working on Netware platforms, it will a great help to improve connectors on this OS. Vote please - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: [ANNOUNCEMENT] Domino / Tomcat connecter available
We could add it to jakarta-tomcat-connector ? +1 -- so long as andy will help fix bugs in it when/if they come :) I'll commit this works on current JTC. I'd like to see this connector supporting others protocol like ajp13 and may be ajp14/warp. It's important to have people working on others platforms for the connector project. We're not in the Java User Land and even if APR will help us be independant from underlying OS, we'll still need good OS specialists -Original Message- From: Andy Armstrong [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 1:05 PM To: Tomcat Dev Subject: [ANNOUNCEMENT] Domino / Tomcat connecter available I've written a Tomcat for Lotus Domino in the spirit of the IIS and Netscape connectors making it possible to use Tomcat as Domino's servlet container. It can be found at http://free.tagish.net/domino-tomcat/index.jsp It's quite small and wouldn't look at all out of place in the Tomcat release ;-) -- Andy Armstrong, Tagish
web_app in JTC
Did you, Pier, agree to move the mod_webapp/warp stuff in jakarta-tomcat-connector and use these CVS instead the one from TC 4.0 ? Having all the connector stuff in a common area will help users (it's what we want), and could also allow us to have a release rate different from the main servlet-engine rate (TC 3.2/3.3/4.0). We could concentrate on common documentation, faq and so-on. We migth even see people using others servlet-engine, like jetty, using the jakarta-tomcat-connector to have a connector for their prefered servlet-engine. Where could I find a description of warp protocol ? As you know I started to work on ajp13 successor, ajp14 and like to see if we could merge the both. Also do you consider adding to mod_webapp the support for load-balancing and fault-tolerance ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: mod_jk for Apache 2.0 not building on Red Hat 6
Something I know well :) Which version of Apache 2.0 have you ? Up to the latest, the apxs was broken. I recommand you take a look at Makefile.linux in TC 3.3 :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Jeffrey Altman [mailto:[EMAIL PROTECTED]] Sent: Friday, June 01, 2001 2:27 PM To: [EMAIL PROTECTED] Subject: mod_jk for Apache 2.0 not building on Red Hat 6 I'm sorry if this is the wrong mailing list to request help for mod_jk for Apache 2.0. If it is, please point me in the proper direction. I am attempting to build mod_jk for Apache 2.0 on Red Hat 6.0. I'm using the build-unix.sh script. Unfortunately, the command $APXS -c -o mod_jk.so $INCLUDE $LIB $SRC does not produce an output file mod_jk.so and it does not indicate why. The file .libs/libmod_jk.a is being produced. Does anyone have any suggestions as to where I should look to determine why the .so file is not being produced? Thanks. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. SSH soon to follow.
RE: mod_jk for Apache 2.0 not building on Red Hat 6
Something I know well :)
Which version of Apache 2.0 have you ?
Up to the latest, the apxs was broken.
I recommand you take a look at Makefile.linux
in TC 3.3 :)
Thanks for your help. The Apache version is 2.0.16
I've looked at the Makefile.linux and that apparently has less luck
than build_unix.sh. It calls
mod_jk.so:
$(APXS) -I ${JK} ${JAVA_INCL} -c -o mod_jk.la mod_jk.c $(SRCS)
mv .libs/mod_jk.so .
You got the Apache 2.0 with the buggy apxs. Please try Apache 2.0.18
or apply the attached path to Apache 2.0 apxs :)
Here is my dump (using jk in JTC) :
/usr/sbin/apxs2 -DUSE_APACHE_MD5 -I ../common -I /opt/IBMJava2-13/include -I
/opt/IBMJava2-13/include/linux -c -o mod_jk.la mod_jk.c
../common/jk_ajp12_worker.c ../common/jk_connect.c ../common/jk_msg_buff.c
../common/jk_util.c ../common/jk_ajp13.c ../common/jk_jni_worker.c
../common/jk_pool.c ../common/jk_worker.c ../common/jk_ajp13_worker.c
../common/jk_lb_worker.c ../common/jk_sockbuf.c ../common/jk_map.c
../common/jk_uri_worker_map.c ../common/jk_ajp14.c
../common/jk_ajp14_worker.c ../common/jk_md5.c ../common/jk_context.c
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o mod_jk.lo mod_jk.c touch mod_jk.slo
mod_jk.c: In function `ws_write':
mod_jk.c:272: warning: initialization discards `const' from pointer target
type
mod_jk.c: In function `init_ws_service':
mod_jk.c:418: warning: assignment discards `const' from pointer target type
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_ajp12_worker.lo ../common/jk_ajp12_worker.c touch
../common/jk_ajp12_worker.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_connect.lo ../common/jk_connect.c touch
../common/jk_connect.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_msg_buff.lo ../common/jk_msg_buff.c touch
../common/jk_msg_buff.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_util.lo ../common/jk_util.c touch
../common/jk_util.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_ajp13.lo ../common/jk_ajp13.c touch
../common/jk_ajp13.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_jni_worker.lo ../common/jk_jni_worker.c touch
../common/jk_jni_worker.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_pool.lo ../common/jk_pool.c touch
../common/jk_pool.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_worker.lo ../common/jk_worker.c touch
../common/jk_worker.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_ajp13_worker.lo ../common/jk_ajp13_worker.c touch
../common/jk_ajp13_worker.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_lb_worker.lo ../common/jk_lb_worker.c touch
../common/jk_lb_worker.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_sockbuf.lo ../common/jk_sockbuf.c touch
../common/jk_sockbuf.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2
RE: mod_jk for Apache 2.0 not building on Red Hat 6
I used the following RPM libtool-1.3.4-3 autoconf-2.13-5 automake-1.4-6 - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Jeffrey Altman [mailto:[EMAIL PROTECTED]] Sent: Friday, June 01, 2001 5:08 PM To: [EMAIL PROTECTED] Subject: RE: mod_jk for Apache 2.0 not building on Red Hat 6 I applied the patch to APXS. I replaced /usr/bin/libtool (version 1.3.4) with the one from the Apache 2.0 distribution (version 1.3.4-freebsd-ports). ./build-unix.sh now completes successfully and produces [root@IAM40 apache2.0]# ls -l /usr/local/apache2/modules/ total 12 -rw-r--r-- 1 root root10802 Jun 1 07:45 libmod_jk.a but no mod_jk.so file. Anyway to convert from .a to .so? make -f Makefile.linux is still failing. So I wonder, which version of libtool are you using? BEGIN make -f Makefile.linux ./apxs -I ../common -I /opt/IBMJava2-13/include -I /opt/IBMJava2-13/include/linux -c -o mod_jk.la mod_jk.c ../common/jk_ajp12_worker.c ../common/jk_connect.c .. /common/jk_msg_buff.c ../common/jk_util.c ../common/jk_ajp13.c ../common/jk_jni_worker.c ../common/jk_pool.c ../common/jk_worker.c ../common/jk_ajp13_worker.c . ./common/jk_lb_worker.c ../common/jk_sockbuf.c ../common/jk_map.c ../common/jk_uri_worker_map.c libtool --mode=compile gcc -pthread -I/usr/local/apache2/include -I../common -I/ opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -c mod_jk.c touch mod_jk.slo mkdir .libs gcc -pthread -I/usr/local/apache2/include -I../common -I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -c mod_jk.c -fPIC -DPIC -o .libs/mod_jk.lo gcc -pthread -I/usr/local/apache2/include -I../common -I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -c mod_jk.c -o mod_jk.o /dev/null 21 mv -f .libs/mod_jk.lo mod_jk.lo libtool --mode=link gcc -pthread -o mod_jk.la -rpath /usr/local/apache2/modules -module -avoid-version mod_jk.lo rm -fr .libs/mod_jk.la .libs/mod_jk.* .libs/mod_jk.* gcc -shared -Wl,--rpath -Wl,/usr/local/apache2/modules mod_jk.lo -pthread -lc -Wl,-soname -Wl,mod_jk.so -o .libs/mod_jk.so creating mod_jk.la (cd .libs rm -f mod_jk.la ln -s ../mod_jk.la mod_jk.la) libtool --mode=compile gcc -pthread -I/usr/local/apache2/include -I../common -I/ opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -c ../common/jk_ajp12_worker.c touch ../common/jk_ajp12_worker.slo rm -f .libs/jk_ajp12_worker.lo gcc -pthread -I/usr/local/apache2/include -I../common -I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -c ../common/jk_ajp12_worker.c -fPIC -DPIC -o .libs/jk_ajp12_worker.lo gcc -pthread -I/usr/local/apache2/include -I../common -I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -c ../common/jk_ajp12_worker.c -o jk_ajp12_worker.o /dev/null 21 mv -f .libs/jk_ajp12_worker.lo jk_ajp12_worker.lo libtool --mode=link gcc -pthread -o ../common/jk_ajp12_worker.la -rpath /usr/local/apache2/modules -module -avoid-version ../common/jk_ajp12_worker.lo rm -fr ../common/.libs/jk_ajp12_worker.la ../common/.libs/jk_ajp12_worker.* ../common/.libs/jk_ajp12_worker.* (cd ../common ln -s jk_ajp12_worker.lo jk_ajp12_worker.o) gcc -shared -Wl,--rpath -Wl,/usr/local/apache2/modules ../common/jk_ajp12_worker.lo -pthread -lc -Wl,-soname -Wl,jk_ajp12_worker.so -o ../common/.libs/jk_ajp12_worker.so gcc: ../common/jk_ajp12_worker.lo: No such file or directory apxs:Break: Command failed with rc=65536 make: *** [mod_jk.so] Error 1 ###END Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. SSH soon to follow.
RE: A starting point for ajp13, ajp14/warp anyone?
jakarta-tomcat-connector is the safe place to put experimental code, like Domino redirector. Also we could hope this sub-project could be one day the reference of connectors between majors Web-Servers and jakarta Servlet Engines :) It's an arena where there we may speak more on native problems (OS, web-server, autoconf, libtool, apr) than Java :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Andy Armstrong [mailto:[EMAIL PROTECTED]] Sent: Friday, June 01, 2001 9:58 PM To: [EMAIL PROTECTED] Subject: Re: A starting point for ajp13, ajp14/warp anyone? Thanks for that Kevin. Pardon my ignorance ;-) kevin seguin wrote: tomcat 4 is not the right place to look for ajp13 examples. ajp14 is still in the early stages, so you're probably better off starting with ajp13. jakarta-tomcat-connectors/jk is probably the best place to look for examples. there are ajp13 connectors for apache, iis and netscape. you're domino connector is also there now, i think :) Andy Armstrong wrote: Hi, This weekend I'm going to look at making the Domino connector we released this week use ajp13 or ajp14 or both. Can anyone give me a quick pointer to which source I should grab from where (or a meta pointer to something I can read to find out) to get started. I had a quick look at the Tomcat 4 sources -- am I right in thinking that the only ajp14 connector that exists at the moment is the Apache one? Sorry if this is an rtfm -- I've had a quick look round the site but couldn't find much. -- Andy Armstrong, Tagish -- Andy Armstrong, Tagish
RE: [ANNOUNCEMENT] Domino / Tomcat connecter available
GOMEZ Henri wrote: We could add it to jakarta-tomcat-connector ? +1 -- so long as andy will help fix bugs in it when/if they come :) I'll commit this works on current JTC. I'd like to see this connector supporting others protocol like ajp13 and may be ajp14/warp. I've just been testing it against ajp13 and it seems fine -- did you think there might be a problem with it? Or was it just because it wasn't tested? i just wasn't tested and you're now our resident expert in Domino and Tomcat connection. Welcome on-board...
RE: [Patch]jk_isapi_plugin.c, Virtual Server support for IIS
Attached is a patch for jk_isapi_plugin.c and a example uriworkermap.properties file. This patch adds some syntax sugar to uriworkermap.properties file format to allow fine grained control over redirection of tomcat contexts to IIS virtual hosts, allowing a syntax like : /www.somevirtualhost.com/context/*.jsp=ajp13 We have this ability under Apache 1.3 by defining the JkMount in virtual server (thus lower cost since the scan will be done only against this virtual server) in UWM.P file.. in addition to the old one of : /context/*.jsp=ajp13 The old syntax comprises the mapping for the entire server, that is this context are honored in all IIS virtual servers.. Why i'm sending a patch and not committing it directly? I'm not sure if the patch ( mostly a hack ) has the merit to go to the repository,as it doubles the number of scans throught the map array, is one of the most wanted TC feature a critical piece, and the patch goes directly to his heart where performance is crucial ...i prefer to hear from people before commit.. What's the size of a standard map array ? Did you see a great loss of performance in that case ? You add the ability to handle the virtual host also in IIS and such new feature may be needed by many users. I'm +1
More on ajp14
Hi to all, The work in still on progress on AJP14 and I've got new questions on ajp14. 1) AJP14 could be considered like an evolution of AJP13. Basically the same protocol but with added commands. AJP13 use the 'AB' chars in start of protocol, what about using something like 'DE' in the case of AJP14. It will help detect and fixes problem when trying to use AJP14 on AJP13. Smarted servlet engine could even route the incorrect ajp protocol 2) Servlet 2.3 (I can't get the Proposed Final Draft 2) add as requirement cipher_suite and key_size. cipher_suite is allready present in current ajp13. I've added key_size to a test ajp13 but adding it to current ajp13 may break compatibility since I'll add a command #11 in the ajp13 stream, something which will not be understand by current ajp13 java implementation. So what to do now ? a) Freeze the ajp13 in all branches and add the key_size only in ajp14 b) add key_size to ajp13 in mod_jk (in jtc) and in all the java implementations ? I've done the b) case, and so I've adapated mod_jk (native) and ajp13 (java for TC 4.0) on jakarta-tomcat-connector to recognize and use the new command. I attached the diff :) Even if I've worked on the b) case, I think it will be more secure to use a) and freeze ajp13 now Just to keep compatibility with TC 3.2.2 which are now closed to new features an which didn't require the Servlet 2.3 compatibility. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 java.diff native.diff
FYI : JSR-000053 Proposed Final Draft 2 Unavailable
Servlet 2.3 API and JSP 1.2 are unavailable at : http://jcp.org/aboutJava/communityprocess/first/jsr053/index.html Clicking on continue for 2.3 or 1.2 give you to : http://java.sun.com/Download4 Any idea where we could find the latest Draft ?
