RE: Error? org/apache/ajp/tomcat4/Ajp13Connector createProcessor()
seems like a bug.
either way, I believe the org.apache.ajp package is deprecated.
-Original Message-
From: eric scroger [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 02, 2002 12:40 PM
To: Tomcat Developers List
Subject: Error? org/apache/ajp/tomcat4/Ajp13Connector
createProcessor()
Greetings,
We were noticing some 'No processor available' exceptions
associated with the Ajp13Connectors under heavy load.
I downloaded the Tomcat 4.0.6 connectors source and had
a look at the code responsible for creating a new processor to
handle an incoming Ajp13 socket connection from Apache.
In org.apache.ajp.tomcat4.Ajp13Connector.java, in the
createProcessor() method, I noticed that there was no logic
to handle the case if maxProcessors was configured to -1
for infinite processors. In the HttpConnector source, if
maxProcessors was -1, then it returned a newProcessor().
I modified this createProcessor() method to function in the
same manner and the Ajp13 No processor available
exceptions disappeared.
private Ajp13Processor createProcessor() {
synchronized (processors) {
if (processors.size() 0)
return ((Ajp13Processor) processors.pop());
if ((maxProcessors 0) (curProcessors maxProcessors))
return (newProcessor());
else {
if ((maxProcessors 0))// my new code
returns a new
processor
return (newProcessor());// if maxProcessors
is -1,
aka infinite.
else return (null);
// original else return result
}
}
}
My question then, is this a bug in the Ajp13Connector functionality?
Or is there some design reason to not allow the user to configure
the Ajp13Connector for infinite processors via the -1 option.
I couldn't locate any documentation that says Ajp13 connectors
cannot and should not be configured for infinite processors.
Thanks,
Eric Scroger
--
To unsubscribe, e-mail:
mailto:tomcat-dev- [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: AJP13,Tomcat404 and SSL
the ajp13 protocol does not support ssl. the isssl flag you are refering to is probably the ajp request attribute that indicates whether or not the request to the web server was using https. -Original Message- From: Gernot Lepuschitz [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 22, 2002 7:59 AM To: [EMAIL PROTECTED] Subject: AJP13,Tomcat404 and SSL As i mentioned last time, i´m writing an AJP Client for our server. Now that ajp13 supports ssl, I want to implement it, too. But I don´t really understant how this will work. I first thought about an Inet-socket-ssl connection to Tomcat where the whole AJP Request will be ssl encrypted. But then I remembered the isssl flag within the AJP Protocol, so I thought, that maybe only the http headers are ssl encrypted (somekind of tunneling the http headers from the browser to Tomcat without decryption between). But that won´t work because I have to encode the Strings of the http headers (key,value). So, could you tell me how it works? Many thanks, Gernot -- To unsubscribe, e-mail: mailto:tomcat-dev- [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: servlet authentication
i could be wrong, but i think once you call sendError(), the response is committed and
you cannot set any more headers. try reversing the order of the
sendError()/setHeader() calls:
response.setHeader(WWW-Authenticate, BASIC realm=\test\);
response.sendError(response.SC_UNAUTHORIZED);
-Original Message-
From: Michael Bergknoff [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 01, 2002 9:02 PM
To: [EMAIL PROTECTED]
Subject: servlet authentication
To test servlet-based authentication, I have a two
line servlet.
response.sendError(response.SC_UNAUTHORIZED);
response.setHeader(WWW-Authenticate, BASIC
realm=\test\);
Here is the output I get:
$ telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /myapp/servlet
htmlheadtitleApache Tomcat/4.0.3 - Error
report/titleSTYLE!--H1{font-family :
sans-serif,Arial,Tahoma;color : white;background-color
: #0086b2;} BODY{font-family :
sans-serif,Arial,Tahoma;color : black;background-color
: white;} B{color : white;background-color : #0086b2;}
HR{color : #0086b2;} --/STYLE
/headbodyh1Apache Tomcat/4.0.3 - HTTP Status 401
- Unauthorized/h1HR size=1 noshadepbtype/b
Status report/ppbmessage/b
uUnauthorized/u/ppbdescription/b uThis
request requires HTTP authentication
(Unauthorized)./u/pHR size=1
noshade/body/htmlConnection closed by foreign
host.
The output contains no HTTP headers, just some Tomcat
generated HTML. Is this a bug in my servlet test or
what?
Thanks,
Mike
__
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.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]
RE: isapi_redirector2 build using static APR
IMO it would be better to build the non Apache connectors using static APR builds. That way we don't need to ship the extra dll's with the connector. The dll builds are ok for mod_jk2 since Apache is already there. +1 (speaking more as a user than a developer these days ...) It would be quite easy to do that adding /D APR_DECLARE_STATIC /D APU_DECLARE_STATIC, linking with apr.lib and aprutil.lib instead of libapr and libaprutil -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PROPOSAL] tag mod_jk 1.2.1
+1 -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 5:16 AM To: Tomcat Developers List Subject: [PROPOSAL] tag mod_jk 1.2.1 Hi to all, What about tagging the current mod_jk (may be after the latest lb patches) to 1.2.1 ? The goal is to populate the jtc builds directory and make binary available for various platform (Linux, Win32, Netware). webapp should be populated soon (layout is ready) : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/web app/release/v1.2.0/ I'd like to do the same for mod_jk (1.2.1) (layout is ready) http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/ release/v1.2.1/ We need to have known versions for both webapp/jk (not jk2) : - A known place where users could get latest connectors (src/bin). - Will remove duplicate works when a arrive new release of Tomcat 3.3.x or 4.x - Something stable enough to hire people to release package / binaries for multiples platforms (AIX, HPUX, SOLARIS, WIN32, NETWARE, OS400 ;), on multiples processors/archs (ppc, ia32, ia64, os390, sparc, mips) What do you think about ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[coyote/tomcat 3.3.1] content-length header never set?
i was playing around with coyote (v1.0-b8) and tomcat 3.3.1 and i noticed that setting
a content-length header had absolutely no effect. in other words, if i set a
content-length header in a servlet, the http client would never see this header. i
dug around through the code a little and discovered that the following patch fixed
this. now, i really don't know anything about the tomcat 3 internals, or coyote, so,
i really don't know how right this is :)
Index: Tomcat3Response.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3/Tomcat3Response.java,v
retrieving revision 1.3
diff -u -w -r1.3 Tomcat3Response.java
--- Tomcat3Response.java9 Apr 2002 18:37:24 - 1.3
+++ Tomcat3Response.java2 May 2002 03:15:07 -
@@ -91,6 +91,11 @@
super();
}
+public void setContentLength(int contentLength) {
+super.setContentLength(contentLength);
+coyoteResponse.setContentLength(contentLength);
+}
+
/** Attach a Coyote Request to this request.
*/
public void setCoyoteResponse(org.apache.coyote.Response cRes) {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [4.1.0] Anyone testing it ?
i've done some minimal testing. i see the following exception a lot, but that's about it: ServerLifecycleListener: processContainerAddChild: MBeanException java.lang.Exception: ManagedBean is not found with NonLoginAuthenticator at org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:654) at org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:361) at org.apache.catalina.mbeans.ServerLifecycleListener.processContainerAddChild(ServerLifecycleListener.java:820) at org.apache.catalina.mbeans.ServerLifecycleListener.containerEvent(ServerLifecycleListener.java:148) at org.apache.catalina.core.ContainerBase.fireContainerEvent(ContainerBase.java:1394) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:829) at org.apache.catalina.core.ContainerBase.access$0(ContainerBase.java:811) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:182) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:805) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:571) at org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:257) at org.apache.catalina.core.StandardHost.install(StandardHost.java:765) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:492) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:410) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:872) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:368) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1194) at org.apache.catalina.core.StandardHost.start(StandardHost.java:731) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1186) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:339) at org.apache.catalina.core.StandardService.start(StandardService.java:496) at org.apache.catalina.core.StandardServer.start(StandardServer.java:699) at org.apache.catalina.startup.CatalinaService.start(CatalinaService.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.BootstrapService.start(BootstrapService.java:219) at org.apache.catalina.startup.BootstrapService.main(BootstrapService.java:279) -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 30, 2002 4:50 AM To: Tomcat Developers List Subject: [4.1.0] Anyone testing it ? Is anyone testing 4.1.0 ? The URL as a reminder: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.1.0/ Obviously, I expect people voting to rate the build to have tried it ;-) Of particular interest is testing: - AJP 1.3 support - To see if bug 5735 is fixed with the current Coyote connector - Jasper 2 Thanks, 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: [4.1.0] Anyone testing it ?
i've done some minimal testing. i see the following exception a lot, but that's about it: The JMX stuff doesn't like you having a custom component defined in your server.xml (you do have one, right ?). So the exception you see indicates the JMX features, including the admin webapp, won't work. If you don't want to see it, you can disable the JMX features by removing the following listener from the server.xml: Listener className=org.apache.catalina.mbeans.ServerLifecycleListener debug=0/ Remy what constitutes a custom component? i didn't add anything to server.xml, just uncommented some things and commented out some other things... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: How can I install Tomcat 4.0 as a plug-in of IIS 5.1?
at one point there was a tomcat-util.jar that was missing some resource bundles (some LocalStrings.properties files) i can't remember exactly what the error(s) looked like for this, but you might try the latest tomcat 4.0.4 beta 2 release. -kevin. -Original Message- From: Luca Ventura [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 4:40 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: How can I install Tomcat 4.0 as a plug-in of IIS 5.1? Hello! My name is Luca Ventura and I am an italian student. I have Microsoft IIS Web Server (5.1) on a PC with Win XP Professional installed and JDK 1.4. I would like to install Apache Tomcat 4.0 as a plug-in to support JSP and Servlets but until now all my tries have been unsuccessful. I have downloaded Tomcat 4.0 at URL: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4 .0.3/bin/ I have downloaded the two versions of Tomacat: jakarta-tomcat-4.0.3-LE-jdk14.exe (for JDK 1.4) jakarta-tomcat-4.0.3.exe (for JDK 1.2+, it also contains other J2EE libraries). Then I have followed the instructions for installing Tomcat 4 as a plug-in of ISS present at URL: http://members.ozemail.com.au/~lampante/howto/tomcat/iisnt/ and at URL: http://jakarta.apache.org/tomcat/tomcat-3.2-doc/tomcat-iis-howto.html The problem is that when I start Tomcat and IIS and I try to access to a JSP page I obtain the error showed by picture error_tomcat.jpg, that I inserted in attach. The class org.apache.tomcat.util.http.BaseRequest is present in tomcat-util.jar present in dir_inst_tomcat4\server\lib but it seems that Tomcat doesn't find that package (and the method authorization() of the class BaseRequest), but I don't know why. What must I do? Is there some configuration file in Tomcat where must I set the .jar files to use? Or must I insert them in the environment variable CLASSPATH? Then I want to point out that I want to configure Tomcat not as an NT service but I want to start it when I need accessing to start menu of Windows. I tried to use the isapi filter isapi_redirector.dll I found at: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4 .0.3/bin/win32 / instead of isapi_redirect.dll present in tc4ntiis.zip (you can download it at url: http://members.ozemail.com.au/~lampante/howto/tomcat/iisnt/ ), but the result is the same. What can I do? Is there some can suggest to me some link I can use to configure IIS and Tomcat 4 correctly? I have seen that in Jakarta web site there are instructions to set Tomcat 3 with IIS but Tomcat 4 is very different. I pray you to tell me how to set all environments and configuration files of Tomcat too :) Thanks a lot in advance. Luca -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: ISAPI or IIS ?
i think the isapi directory was an experiment that was never followed through on. pretty sure you want to go with the stuff in the iis directory. i don't think you need both. -kevin. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 02, 2002 11:09 AM To: Tomcat Developers List Subject: ISAPI or IIS ? I'll start updating the IIS stuff - there are 2 dirs in jk1 - iis and isapi. Which one is used ? From what I can read 'isapi' is newer and seems more generic, is this right ? Do we need both for jk2 ? ( BTW, lots of duplicated code will go away or be moved to the core, and the registry reading stuff should be refactored in a jk_config_registry ) 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: [VOTE] Tomcat 4.0.4 Beta 2 / Coyote 1.0 Beta 4 release
Tomcat 4.0.4 Beta 2 release: ballot +1 [ ] I support the release, and I will help +0 [ ] I support the release -0 [ ] I don't support the release -1 [ ] I'm against the release because: /ballot +0 Inclusion of the Coyote binaries: ballot +1 [ ] Yes -1 [ ] No /ballot +1 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: j-t-c standalone releases ?
+1 -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 10, 2002 4:00 PM To: [EMAIL PROTECTED] Subject: j-t-c standalone releases ? If I remember well, it was decided some time ago it was ok to release connectors as modules for Tomcat. Since I'd like to distribute beta versions of Coyote, I went ahead and created some binary distribution directories. http://jakarta.apache.org/builds/jakarta-tomcat-connectors/coy ote/release/v1 .0-b1/ I labelled it as beta, as it passes the test suites for Tomcat, and was able to sucessfully go through some WebDAV-based uploading test (I didn't test SSL at all, though). This version doesn't include the TC 3 code, as I packaged it yesterday. I plan to link the http://jakarta.apache.org/builds/jakarta-tomcat-connectors/ directory from the Tomcat binary distribution readme http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4 .0.3/README.ht ml and then post an announcement on tomcat-user. Is it ok with everyone ? 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: Jk2 config
1. JkSet NAME VALUE Will have exactly the same behavior as NAME=VALUE in a workers.properties file. All settings that you can do in workers.properties today could be done by JkSet, in httpd.conf. Or all settings could be done in workers.properties. For example JkLogLevel DEBUG will be now: JkSet logLevel DEBUG ( in httpd.conf ) or logLevel=DEBUG ( in workers.propertes ) The first style is for people who prefer working with httpd.conf, the other one will be easier for IIS/iPlanet and may be easier to generate/edit. +1 - i really like the idea of being able to configure the different web servers +(apache/iis/netscape) in a similar fashion. 2. JkWebapp NAME VALUE Set properties on a webapp level. Will be set at Location level. An equivalent setting will be in a uri-workers.properties ( or a better named one ), the same that we use for IIS. JkMount is not doing anything special - it's the same efect as the properties file we use on IIS. Except that properties are easier to generate and will be consistent for all servers ( no longer need to generate 3 different styles ). Location will be used for performance, it uses the apache mapper instead of jk's. +1 for the same reasons as above. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] log output can get messed up with org.apache.catalina.logger.FileLogger
Another way to fix this would be to use String concatenation.
The question
is, which is more expensive, the synchronization or the
String concatenation?
yeah, that occurred to me too... anybody have an answer?
This is how the code would be with String concatenation:
// Log this message, timestamped if necessary
if (writer != null) {
if (timestamp) {
writer.println(tsString + + msg);
} else {
writer.println(msg);
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] log output can get messed up with org.apache.catalina.logger.FileLogger
if a lot of log messages are being written to a file by a lot of threads using
org.apache.catalina.logger.FileLogger, the output can get messed up so that you get
things like this:
[timestamp-1] [timestamp-2] [message-1]
[message-2]
instead of this:
[timestamp-1] [message-1]
[timestamp-2] [message-2]
i ran into this while trying to debug bug 5735, which requires a decent load (i.e.
lots of threads).
attached is a patch with one possible solution - i could commit this, but i generally
don't commit on tomcat4, so i'd like some +1's before committing :)
-kevin.
Index: catalina/src/share/org/apache/catalina/logger/FileLogger.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/logger/FileLogger.java,v
retrieving revision 1.3.2.1
diff -u -b -r1.3.2.1 FileLogger.java
--- catalina/src/share/org/apache/catalina/logger/FileLogger.java 25 Oct 2001
20:07:44 - 1.3.2.1
+++ catalina/src/share/org/apache/catalina/logger/FileLogger.java 19 Feb 2002
+19:44:33 -
@@ -289,13 +289,14 @@
// Log this message, timestamped if necessary
if (writer != null) {
+synchronized (writer) {
if (timestamp) {
writer.print(tsString);
writer.print( );
}
writer.println(msg);
}
-
+}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 5735] - HTTP connector running out of processors under heavy load
--- Additional Comments From [EMAIL PROTECTED] 2002-02-18 00:30 --- Based on the apache logs it looks like when the Ajp13Processor's become unavailable for reuse they have successfully handled a request. I can tell this due to entries existing in the apache access_log for image files, etc. related to a request forwarded to Tomcat via mod_jk being requested. So the problem which is causing the Ajp13Processor's to hang must be in Ajp13Proccessor code after a request has been handled and before it calls connector.recycle(this) to make itself available to process another Ajp request. that would be somewhere in Ajp13Processor.process()... if you can reproduce this consistently, can you turn up the logging for the ajp13 connector, then send me (seguin at apache.org) the all of the pertinent log files and the captured stdout/stderr - unfortunately, some of the ajp stuff logs to stdout :( - from a run where this problem occurs? thanks. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Request.java
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: viernes 15 de febrero de 2002 1:55 Perhaps is better to have explicit control over that, to disable or enable the control of the native auth honoring..the infamous tomcatAuthentication attribute.. I don't quite understand, as the patch only add filtering out an empty string, right ? Or did I miss something ? In any case, I just applied the patch as it looked ok to me. If the patch is bad, revert it. i think native auth honoring is different than the problem this patch addresses. i don't think the patch should be reverted (so long as it works :)). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Fix for AJP13 Connector Authentication Bug !!!
i've tested the patch remy checked in and it's now working for me too. very cool.
thanks guys :)
-Original Message-
From: Jonathan Pierce [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 14, 2002 6:40 PM
To: [EMAIL PROTECTED]
Subject: Fix for AJP13 Connector Authentication Bug !!!
I've confirmed the fix for the AJP13 Connector /
Authentication problem in
4.0.2.
This solves high priority bugs 5647 and 6219.
Please have one of the committers confirm the fix and check
it in to cvs.
The issue was reported in Bug 6219.
I tested the following modification and it seems to resolve
the problem.
The problem is in
org.apache.ajp.tomcat4.Ajp13Request.setAjpRequest The fix is
below:
Replace from line 115:
// String remoteUser = ajp.remoteUser().toString();
// if(remoteUser != null)
// setUserPrincipal(new Ajp13Principal(remoteUser));
String remoteUser = ajp.remoteUser().toString();
if ((remoteUser != null) (! remoteUser.equals ()))
{
setUserPrincipal(new Ajp13Principal(remoteUser));
}
else
{
setUserPrincipal(null);
}
After making this modification, I am able to successfully
serve the protected
example url through the IIS connector and get properly
challenged by the login
screen and am able to login and logout as expected.
http://localhost/examples/jsp/security/protected/index.jsp
-Jonathan
**
**
This email and any files transmitted with it are for the
named person's use
only. It may contain confidential, proprietary or legally privileged
information. No confidentiality or privilege is waived or lost by any
mistransmission. If you receive this message in error,
please immediately
delete it and all copies of it from your system, destroy any
hard copies
of it and notify the sender. You must not, directly or
indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient.
This email message has been swept by a virus software product for the
presence of computer viruses.
**
***
--
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: Native Connector Builds - When?
i have builds of the iis connector and the netscape connector on solaris (built on 2.6) for jk1. if somebody can tell me what i need to do - how to sign the binaries, where to upload files to - i can provide these. -kevin. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
native connectors for iis and netscape/solaris available
fyi - i've uploaded native jk1 connectors for iis and netscape/solaris. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: native connectors for iis and netscape/solaris available
i've uploaded native jk1 connectors for iis and netscape/solaris. 1. How did you build it? There were files referenced by the Visual Studio projects that were missing in the jakarta-tomcat-connectors-4.0.2-src.zip. When I tried to build it, I needed to add some files from the cvs. You might want to make sure all the needed files are included. These files were referenced in the project, but missing from the /native/common directory. They do exist in the /native2/common directory but introduce other errors if you use these versions. I had to use the versions from the Tomcat3.3a distribution. jk_registry.c jk_channel_socket.c jk_env.c i used ant to build. the visual studio files are apparently out of date. 2. I downloaded the iisapi connector build and it seems to work fine with 4.0.2 with the exception of high priority Bug: 5647 (AJP13 connector will not pass authentication requests). This bug is forcing me to disable the use of Realms in my production application since I need the connector. Does anyone have an estimate on when this bug will be fixed? It is a show stopper for me. when i have time, i plan on looking into it some more. can't give an estimate on that, though. of course, you're more than welcome to fix it and post a patch :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [4.0.2] [VOTE] Final release
+0 actually, +0.5 -- i'll help out if i can :) -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Friday, February 08, 2002 12:32 PM To: [EMAIL PROTECTED] Subject: [4.0.2] [VOTE] Final release Hi, I'd like to propose to release the current code in the 4.0 branch as Tomcat 4.0.2 Final. This release includes lots of bugfixes and improvements, especially in the connectors area, which feature a dramatic improvement over what was available in Tomcat 4.0.1 (this alone justifies making a release IMO, given the amount of problems people are experiencing with the versions packaged in Tomcat 4.0.1). The remaining should-fix bugs resolution will be postponed until a later release. None of them were regression problems. The jakarta-tomcat and jakarta-tomcat-connectors repositories will be tagged with tomcat_402. The tomcat-warp / tomcat-util / warp source will be synced with the sources in the jakarta-tomcat-connectors repository. The binaries will be packaged and be made available for verification by other committers this week-end, and the release announcement will be posted early next week (Monday seems appropriate). As discussed yesterday, the binaries will include a minimal distribution designed to be run on JDK 1.4. ballot [ ] +1 - I support this release and I will help [ ] +0 - I support this release [ ] -0 - I do not support this release, 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]
RE: [4.0.2] [4.1] [PROPOSAL] Binaries packaging
ballot ZIP/TGZ packaging: [ ] Do A [X] Do B [ ] Do C /ballot -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Header handling bug in class org.apache.Ajp13
the fix for this is already in cvs and will be part of the next 4.0.2 beta
release.
-Original Message-
From: Jianliang Zhao [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 04, 2002 4:26 PM
To: Tomcat-dev (E-mail)
Subject: Header handling bug in class org.apache.Ajp13
I enabled AJP 1.3 connector on Tomcat 4.0.1 with Netscape
Server and found a NumberFormatException thrown for a HTTP
request with non-standard headers. I checked out the code
from module jakarta-tomcat-connectors with tag tomcat_401.
After some debuging, it seems the following code is causing
the problem:
method: Ajp13.decodeRequest
Between // are my comments. Would you
please make this fix and let me know where to get a patched
tomcat_ajp.jar file?
// Header names are encoded as either an integer
code starting
// with 0xA0, or as a normal string (in which case the first
// two bytes are the length).
int isc = msg.peekInt();
/***/
// MY DEBUG STATEMENT
System.out.println(header ID: + isc); // It
happens to be 8 for a non-standard header
/***/
int hId = isc 0xFF;
MessageBytes vMB=null;
isc = 0xFF00;
if(0xA000 == isc) {
/***/
// MY DEBUG STATEMENT
System.out.println(Integer coding: 0xA);
/***/
msg.getInt(); // To advance the read position
hName = headerTransArray[hId - 1];
vMB= headers.addValue(hName);
} else {
/***/
/* This branch is executed for the normal
string encoding(non-standard header case)*/
/* The header ID is also set for the normal
string encoding case */
/* I added the following line to fix the problem */
hId = -1; // Should we set hId to dummy number here?
System.out.println(Normal String: 0xA);
/***/
// XXX Not very elegant
vMB = msg.addHeader(headers);
if (vMB == null) {
return 500; // wrong packet
}
}
msg.getMessageBytes(vMB);
// set content length, if this is it...
if (hId == SC_REQ_CONTENT_LENGTH) {
/***/
/* Originally the following line was
executed for normal string encoding if hId happens to be 8 */
/* It throws NumberFormatException */
/***/
int contentLength = (vMB == null) ? -1 :
vMB.getInt();
Thanks,
Jianliang
--
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: DO NOT REPLY [Bug 5647] - AJP13 connector will not pass authentication requests
--- Additional Comments From [EMAIL PROTECTED] 2002-01-31 04:14 --- I have seen the same problem. I applied Adam's patch to jakarta-tomcat-connectors from CVS updated tonight, and HTTP Basic Authentication worked, even over SSL. This was using a build of Tomcat 4.1-dev from a few weeks ago. I have the karma to commit this, but since I don't normally work on the apache connectors, I'll leave the commit to one of the regulars. i'd say go ahead and commit it if you want. i've looked at the patch, and it looked pretty good to me. i just haven't had time to apply it yet. if you don't, i'll eventually get to it :) -kevin. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk bug ?
Hi, I encountered the following error when accessing any java servlet(e.g.http://localhost/servlet/SnoopServlet) through Internet Explorer of PocketPC : Maybe IE for PocketPc is sending some kind of malformed HTTP Request? Or mod_jk native and/or Java part has bug? Please post a bug a http://nagoya.apache.org/bugzilla , TIA. This looks like #5861, which I think should be fixed for 4.0.2 final. There's a patch included with the bug, so if someone could take a look at it and commit it if it's correct, that would be great. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5861 i've tested and committed the patch. good catch guys - thanks! -kevin. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Native2: proposed interface change
What I want is to make the C code implement the same abstractions with the java side and to get JNI to use the same transport abstraction. What do you think ? Henri, JFC, Kevin - I hope for an quick answer :-) it sounds like you're heading towards a good deal of symmetry between the java and c code, which is definitely good :) +1 -kevin. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp Ajp13.java
total_read = readN(in, b, H_SIZE, len);
-
-if (total_read = 0) {
+
+// it's ok to have read 0 bytes when len=0 -- this means
+// the end of the stream has been reached.
+if (total_read 0) {
logger.log(can't read body, waited # + len);
return JK_AJP13_BAD_BODY;
}
Why not just skip the readN call when len = 0 since
the only case where readN will return 0 is when the
passed len is 0 ;)
I'll commit a patch later
yeah, that same thought occurred to me too. but, then i never did anything
about it. i was just happy i figured out what went wrong :)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Tomcat 4.0.2-b2] Java binaries uploaded
I've uploaded the Java binaries for 4.0.2-b2. The official release announcement will be made on Monday (as well as the update of the website). http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.2-b2/ Please upload the RPMs and builds of JK and webapp ASAP. Thanks for everyone's help on putting this release together. It was a real team effort :) there is a problem with the tomcat-util.jar in this distribution. it does not contain the message resources (LocalStings.properties, etc.). i fixed this in j-t-c/jk/build.xml on friday (the 18th), and this file is tagged properly with tomcat_402_b2 did the tomcat-ajp.jar and tomcat-util.jar files not get rebuilt on the tomcat_402_b2 tag? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[j-t-c] building jtc/jk (WAS RE: [Tomcat 4.0.2-b2] Java binaries uploaded)
there is a problem with the tomcat-util.jar in this distribution. it does not contain the message resources (LocalStings.properties, etc.). i fixed this in j-t-c/jk/build.xml on friday (the 18th), and this file is tagged properly with tomcat_402_b2 did the tomcat-ajp.jar and tomcat-util.jar files not get rebuilt on the tomcat_402_b2 tag? as a side note, the new java code in jtc/jk still doesn't build because of dependencies on things like PoolTcpConnector, which i assume are being moved into jtc/util? costin? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Tomcat 4.0.2-b2] Java binaries uploaded
there is a problem with the tomcat-util.jar in this distribution. it does not contain the message resources (LocalStings.properties, etc.). i fixed this in j-t-c/jk/build.xml on friday (the 18th), and this file is tagged properly with tomcat_402_b2 did the tomcat-ajp.jar and tomcat-util.jar files not get rebuilt on the tomcat_402_b2 tag? Yes that's what happened, as I wasn't aware of any changes :-( I'll rebuild the binaries and upload them within a few minutes. sorry about that -- guess i should have told you that's why this is a beta ;-) anyway, this is good because you'll also get the changes for the bug in the old ajp java code that i fixed on friday as well. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [j-t-c] building jtc/jk (WAS RE: [Tomcat 4.0.2-b2] Java binaries uploaded)
as a side note, the new java code in jtc/jk still doesn't build because of dependencies on things like PoolTcpConnector, which i assume are being moved into jtc/util? costin? No, there are some unused imports. I fixed it - please check and let me know if there are still problems. builds perfectly for me now -- thanks :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [j-t-c] HexUtils.java no longer compiles for me...
without explicitly casting each entry in the HEX array to a
byte, like
this:
public static final byte[] HEX =
{ (byte)'0', (byte)'1', (byte)'2', (byte)'3',
(byte)'4', (byte)'5', (byte)'6', (byte)'7',
(byte)'8', (byte)'9', (byte)'a', (byte)'b',
(byte)'c', (byte)'d', (byte)'e', (byte)'f' };
any objections to my checking this in?
+1.
Note: It builds fine for me.
it turns out that i was using an older version of jikes than i thought -
1.12 vs. 1.14. the current code builds fine with jikes 1.14. so, unless
somebody else runs into the same problem, i don't think there's any reason
to make the change.
-kevin.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [j-t-c] post bug in latest ajp (a.k.a. jk1) code
fyi: i have found and fixed this bug. The code for jk and webapp needs to be tagged then. Please let me know when it's done. from my perspective, it's done. don't know about costin, jf, et al, though. -kevin. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[j-t-c] HexUtils.java no longer compiles for me...
without explicitly casting each entry in the HEX array to a byte, like this:
public static final byte[] HEX =
{ (byte)'0', (byte)'1', (byte)'2', (byte)'3',
(byte)'4', (byte)'5', (byte)'6', (byte)'7',
(byte)'8', (byte)'9', (byte)'a', (byte)'b',
(byte)'c', (byte)'d', (byte)'e', (byte)'f' };
any objections to my checking this in?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[j-t-c] post bug in latest ajp (a.k.a. jk1) code
i think i've just run into a bug with doing posts using the latest code found in jtc/jk/java/org/apache/ajp that i'd really like to fix before tomcat 4.0.2b2. although this code will eventually be deprecated by the stuff costin is working on, it is currently the only ajp code that will work with the existing iis and netscape connectors (that i know of, at least). remy, i don't know when you're planning on cutting 4.0.2b2, but i'm going to try to fix this tonight, so hopefully i can get a fix in before beta 2. -kevin. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [j-t-c] post bug in latest ajp (a.k.a. jk1) code
fyi: i have found and fixed this bug. i think i've just run into a bug with doing posts using the latest code found in jtc/jk/java/org/apache/ajp that i'd really like to fix before tomcat 4.0.2b2. although this code will eventually be deprecated by the stuff costin is working on, it is currently the only ajp code that will work with the existing iis and netscape connectors (that i know of, at least). remy, i don't know when you're planning on cutting 4.0.2b2, but i'm going to try to fix this tonight, so hopefully i can get a fix in before beta 2. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Tomcat 4.0.2 b2 release
ballot [X] +1 Make the release [ ] +0 Good idea, but I can't help [ ] -0 Bad idea [ ] -1 No, because: /ballot -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Todo list for 4.0.2 b2
- Did jk from j-t-c for TC 4.0.2B2 will support load balancing ? I didn't see the use of getJvmRoute/setJvmRoute in latest TC 4.0 CVS. nope :( it's never been clear to me exactly what has to be done to support load balancing, so i've never attempted to add the functionality. and it's not something i use, so it obviously doesn't bubble up on my priority list :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Apache mod_jk Ajp13 Tomcat 4 shutdown delay, bug?
I am using Apache mod_jk and Ajp13 to connect to Tomcat 4. When shutting down Tomcat 4 it takes about 15 seconds when using apache for the tomcat process to complete, when using Tomcat 4 standalone shutdown and termination of the process happens almost immediately. Has anyone else seen this behaviour? I have two Ajp13 connections configured between Apache and Tomcat, one for http and one for https. i have checked in a small change to org.apache.ajp.tomcat4.Ajp13Processor that may help speed up shutdown time. see the checkin comment for revision 1.6 of this file for more info. it's not perfect, but it's the best i could hope to do for tomcat 4.0.2 :) -kevin. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Apache mod_jk Ajp13 Tomcat 4 shutdown delay, bug?
I am using Apache mod_jk and Ajp13 to connect to Tomcat 4. When shutting down Tomcat 4 it takes about 15 seconds when using apache for the tomcat process to complete, when using Tomcat 4 standalone shutdown and termination of the process happens almost immediately. Has anyone else seen this behaviour? I have two Ajp13 connections configured between Apache and Tomcat, one for http and one for https. after a brief review of the tomcat4 ajp13 connector, i think the behaviour you are seeing is explained by the way the connector is shut down + the fact that the socket connection between the webserver (apache in this case) and tomcat is reused. the Ajp13Connector creates Ajp13Processor's to handle ajp requests. the processors in turn will create a thread, then in this thread, will get a socket, handle an ajp request, then wait for another request on the socket, blocking. when the connector is stopped, it stops all of its processors. the processors try to stop their threads, waiting for at most 5 seconds before returning. it looks like the processor worker threads never stop, so each processor will take at least 5 seconds to stop. anyway, this will probably make more sense if you follow the stop logic throug starting at: org.apache.ajp.tomcat4.Ajp13Connector.stop() (around line 946) i think Ajp13Connector and Ajp13Processor are more complicated than they need to be. but, that's just thought :) -kevin. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Apache mod_jk Ajp13 Tomcat 4 shutdown delay, bug?
Now the question is... How hard would it be to get the worker threads to block on either the socket OR some type of shutdown event, with either satisfying the wait? ideally :) i think the problem might be that once you're blocked reading on a socket, other than shutting down the socket (i.e. Socket.shutdown()), there's no way to interrupt. i'm not 100% sure on that, though. i need to think about it some more... Those extra seconds required for shutdown count when you have to do a stop/start of tomcat on a production system. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Todo list for 4.0.2 b2
Here goes the list: - Tag the JK + util directories in j-t-c with some tag (Costin proposed jk_14) - Build the corresponding JK binaries i've successfully built and used the following, and can provide binaries if necessary (all jk1, btw): - iis connector - netscape connector on solaris 2.6 (upwards compatible with 2.6+) - Write some documentation about the new auto-configuration mechanism (but it can wait until 4.0.2 Final) - Update the AJP page in the docs with other changes for AJP 1.4, if any - Tag the warp directories in j-t-c (JF or Pier can you do that ?) - Build the corresponding mod_webapp binaries - And of course build the main binaries and upload them According to Costin, JK 1.4 is ready or almost ready. If it's not done yet, is it doable by the end of the week ? to the best of my knowledge, the jk (a.k.a. jk1) code, including some 1.4 functionality, is stable. i think it's the jk2 code that costin is still working on. and i think jk2 will be experimental or alpha at best for 4.0.2. -kevin. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: tomcat 4.0.2 and jakarta-tomcat-connectors
I think we should tag the code with jk_1_4 ( considering the jk that was included with 3.1 == jk1.1, etc ). It seems jk_1_4 will work with 3.3, 4.0.x and 4.1 ( and the C code can be used for 3.2.x for bug fixes ). jk_1_4 is fine with me -- as long as it is tagged with something :) Regarding jk2, I'm still working, the current strugle is with the unix domain sockets ( since JFC commited the jk implementation, and I promised I'll do the java side ). I did some more changes in mod_jk(2) config, now seting JkWebapp in a Location context works for virtual hosts and almost everything else. I do plan few more config changes - automatically restrict WEB-INF, etc, and I want to get at least basic info out of the status worker. On the java side we have a first version, but I still have to integrate it with either the interceptor/connector, or ( assuming everything works as it seems ) in JkServlet ( using what I proposed last year, i.e. web.xml/'standard' servlets + 'trusted apps' + a bit of magic). Sorry it takes so long, but I have a lot of other work to do... i was thinking that for tomcat 4.0.2, the old stuff, jk/native, jk/java/org/apache/ajp, would be considered the 'stable' (althought still beta quality) code, and the new jk2, o.a.jk would be considered still 'experimental'. just a thought, though - i don't know that much about the new code :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: tomcat 4.0.2 and jakarta-tomcat-connectors
I think we should tag the code with jk_1_4 ( considering the jk that was included with 3.1 == jk1.1, etc ). It seems jk_1_4 will work with 3.3, 4.0.x and 4.1 ( and the C code can be used for 3.2.x for bug fixes ). +1. When it's done and when you can confirm it's working, I think we can release 4.0.2 b2 (I have only a few patches to commit to the branch and it should be ok). i believe the jk (not jk2) code, both native (jk/native) and java (jk/java/org/apache/ajp), in j-t-c to be working and in a stable state. Could we do the same for webapp ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
tomcat 4.0.2 and jakarta-tomcat-connectors
there was a thread a couple weeks ago regarding what to do with j-t-c and tomcat 4.0.2. i believe it was decided that the 4.0.2 release would contain the same jars from j-t-c (tomcat-ajp.jar, tomcat-util.jar) as 4.0.1 did. well, i just did some quick tests with the 4.0.2-b1 dist and the head of j-t-c, and all seemed to be in working order. so, i think it might be a good idea to try to release the latest stuff from j-t-c with 4.0.2 for a couple of reasons: *) if we release and tag j-t-c along with jakarta-tomcat-4.0, i think it'll be easier to do maintenance, fix bugs, etc.. i'm not only talking about the java code in j-t-c, but also the c code. *) there have been some bug fixes in j-t-c since 4.0.1 -- these may as well be released :) thoughts? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JK binaries
I'm trying to figure out what I should do with the AJP binaries, as the CVS is a bit messy at the moment (and it includes two versions of the sources). I can: - keep the current binary for b1 - try to upgrade, but I'd like to know which one I should use (and the build script should be fixed) i think it would be best to use the lastest stuff in jk/java/org/apache/ajp. it was working as recently as last week with tomcat 4.0.1. i think costin is putting his new code in jk/java/org/apache/jk. i can make sure jk/java/org/apache/ajp is building and working with the 4.0.2 binaries. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Connector compatibility between TC 4.0 and 4.1
Hi, After a lot of efforts, it turns out the connectors (in j-t-c) still can't be compiled against both the 4.0 branch and the HEAD branch of the Tomcat CVS. There are a few solutions to this: 1) Force the connectors to be built against the HEAD branch. They should run fine on Tomcat 4.0 (although that needs some testing). 2) The main problem is the move of the ServerSocketFactory interface from o.a.c.net to o.a.c. We could revert that change, and fixing the rest is extremely simple. Which one do you think is best ? perhaps now is the time to do some rethinking of where the connectors for each serlvet container live. today, in j-t-c, there is the framework (for lack of a better word) for connectors plus the individual connectors or adapters for tomcat 3 and tomcat 4. personally, i think it would be better to have the individual connectors/adapters live with the servlet container itself. i.e. put the ajp13 connector for tomcat 4 in the jakarta-tomcat-4.0 source tree. this way, j-t-c can build without having dependencies on any servlet containers, and servlet containers that want to provide connectors that make use of j-t-c can (optionally) depend on j-t-c. just my $0.02. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JK binaries
I'm trying to figure out what I should do with the AJP binaries, as the CVS is a bit messy at the moment (and it includes two versions of the sources). I can: - keep the current binary for b1 - try to upgrade, but I'd like to know which one I should use (and the build script should be fixed) i think it would be best to use the lastest stuff in jk/java/org/apache/ajp. it was working as recently as last week with tomcat 4.0.1. i think costin is putting his new code in jk/java/org/apache/jk. i can make sure jk/java/org/apache/ajp is building and working with the 4.0.2 binaries. i take it all back :) i just updated j-t-c/jk and i can't build it. and i don't have time to try to figure it out right now. sorry. so, maybe it's best for now to go with the current binary. -kevin. -- 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 :) 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]
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 :))) how does the connector set/use jvmroute? i assume there is some sort of cookie magic going on, but after a brief tour of the code, it's not obvious to me how this jvmroute stuff works. it seems to me that tomcat (any version) shouldn't have to have anything to do with setting jvmroute. couldn't the connector be solely responsible for this? the connector could add a cookie to the response, then read this cookie on subsequent requests, and then you wouldn't have to add stuff to servlet containers to handle this. or, i could be totally off base :) -kevin. -- 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 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 ? it does seem like j-t-c might be reaching the critical mass where it warrants its own list. -- 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
Catch me if I'm wrong, but currently j-t-c is dependent on tomcat code, right? I make this statement without having actually looked at the code for the connectors. I'm going by recent discussions about how an API change in Catalina broke the build for a connector. some very small parts of jtc are dependent on tomcat. these are the adapters/connectors for tomcat. much of what is in jtc is totally tomcat-agnostic, and is buildable without tomcat. personally, i believe the adapters/connectors for each servlet container (tomcat3, tomcat4, perhaps jetty someday) should exist in the container module, and the container modules should depend on jtc, not the other way around. just my $0.02. -kevin. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
org.apache.tomcat.util.net package in tomcat 3.x
it seems like a bunch of the stuff in the org.apache.tomcat.util.net package in tomcat 3.x would be useful outside the scope of tomcat 3. most notably, things like TcpConnection, TcpConnectionHandler, PoolTcpEndpoint. what would people think about moving (or at least copying for now) this package into j-t-c/util? a bunch of the subpackages of o.a.t.util in tomcat 3 have already been moved there. the reason i bring this up is i think i'd like to use some of this stuff for the refactored ajp stuff i'm doing in j-t-c/jk. -kevin. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2: error handling and method signatures
One more change I want to do in jk2 is better error handling. Most of us spent enough time with java that using an 'int' is very uncomfortable :-) error handling good :) whether this is done by return codes, exceptions, etc., personally, i don't care. what i do care about is consistency -- the same error-handling techniques used throughout jk. My proposal is to use jk_env in the same 'style' as in JNI programming. Each jk method will have as the first parameter a jk_env *env ( that requires just a bit of regexp ). Before the first call to a jk method, we'll use a jk_getEnv, which will return a (pooled) jk_env. env will have errorString, errorFile, eventually a method throw() that will set the things. This would allow mod_jk to report the exact problem. yes! an error string to explain exactly what went wrong would be great. Exactly the same method is used in jni - a jni worker could actually wrap JNIEnv. I also believe the code will be easier to read this way. This is obviously not 'required' - we can live without it. Please let me know what you think - I implement it pretty quickly. it all sounds pretty reasonable to me. -kevin. -- 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 ). by part, you mean o.a.t.util.buf|collections|http|res, right? But if we do that, I would propose to _move_ it, not copy. ideally, you'd move the rcs archives to maintain history. however, doing that would presumably break all tomcat 3.x builds. i guess the next best alternative would be to move the rcs archives. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[j-t-c] patch for jakarta-tomcat-connectors/jk/native/common/jk_ajp_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. jtc.jk.patch Description: Binary data Upload2.java Description: Binary data FileUpload.java Description: Binary data -- 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
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. This seems to be the main problem we had so far with jk - buffers beeing reused before they're ready. For jk2 we must make sure we have more control over that or allocate enough buffers. i think in this case it's the wrong buffer being used -- the post data is being read into the reply buffer rather than into the post buffer that will be sent to the java side. 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 ... ;) You fixed what branch :-) ? I'll try to reproduce this. i haven't checked anything in yet because i'm not positive i'm right -- not familiar enough with the code, don't want to break anything else! :) -kevin. -- 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
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 ... ;) well, i'm pretty sure i figured out this one. RequestHandler.refillReadBuffer() is missing the all important check for the empty packet that signals the end of the stream :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
tomcat 4 and response buffer size
i just happened to notice that the behaviour of tomcat 4 response buffers
might not be as expected with respect to buffer size. below is some code
from org/apache/catalina/connector/ResponseBase.java:
--- snip ---
public void write(byte b[], int off, int len) throws IOException {
if (suspended)
throw new IOException
(sm.getString(responseBase.write.suspended));
// If the whole thing fits in the buffer, just put it there
if (len == 0)
return;
if (len = (buffer.length - bufferCount)) {
System.arraycopy(b, off, buffer, bufferCount, len);
bufferCount += len;
contentCount += len;
return;
}
// Flush the buffer and start writing full-buffer-size chunks
flushBuffer();
int iterations = len / buffer.length;
int leftoverStart = iterations * buffer.length;
int leftoverLen = len - leftoverStart;
for (int i = 0; i iterations; i++)
write(b, off + (i * buffer.length), buffer.length);
// Write the remainder (guaranteed to fit in the buffer)
if (leftoverLen 0)
write(b, off + leftoverStart, leftoverLen);
--- end snip ---
it looks like when you are writing to a response, and the size of the new
chunk of data + the size of the existing data in the buffer is greater than
the buffer size, the existing data will be written to the client, then the
new data will be added to the buffer and all or part of it possibly written
to the client.
it may not make much of a difference, but i would have expected the internal
buffer to be completely filled before data is sent to the client.
for example, suppose your buffer size is 8K. if you write 1 byte to the
response, then write 8K to the response, first 1 byte will be written to the
client, then 8K will be written to the client. i would have expected this
to be the other way around.
probably not a big deal, just thought i'd point it out :)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[j-t-c] ajp and headaches
after many months of being away, i've recently gotten back into the fray of jakarta-tomcat-connectors. my goal is as it was many months ago - an ajp (v1.3) connector for tomcat 4. after discovering that things are not working entirely correctly on the HEAD of cvs, i started digging into the code in both places. maybe it's just me, but i found trying to follow the java code particularly painful. i realize there is some development and refactoring going on with ajp14 and all, but man!, it ain't pretty in there :) so, partly out of sheer necessity, and partly because i think it would be useful, i'm considering doing a major rewrite - no, let's call it refactoring :) - of the java code in j-t-c/jk. the goal would be correctness, clean up and simplification. i would start with ajp13, but keep in mind there is ajp14, ajp15, etc., to come. i think i would do this on a branch, too, call it ajp_refactoring, or something like that. what are the thoughts on this? thanks, -kevin. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [j-t-c] ajp and headaches
I think we agreed ( Henri had some doubts ) that ajp14 will consist only on additional messages, but all the low-level messaging stuff will be ajp13. For that we only need a mechanism to register new message handlers, and to have a dispatcher that calls the right handler when a packet is received. that sounds reasonable. so, partly out of sheer necessity, and partly because i think it would be useful, i'm considering doing a major rewrite - no, let's call it refactoring :) - of the java code in j-t-c/jk. the goal would be correctness, clean up and simplification. i would start with ajp13, but keep in mind there is ajp14, ajp15, etc., to come. i think i would do this on a branch, too, call it ajp_refactoring, or something like that. what are the thoughts on this? +1, I was thinking the same :-) I would propose doing it in the main branch, but with a separate package name. I can roll back my changes in o.a.ajp - and revert it to the 'stable', and move to a new package ( I was thinking o.a.jk or o.a.jk2 - since it'll not be specific to ajp, but will also have jni and maybe other). separate package, main branch makes sense. i like org.apache.jk. depending on the amount of free time i find before the hollidays, you may start seeing checkins there :) Right now I'm trying to do some rewriting/optimizations/apr-istaion on the C side, I hope to finish most of it next week ( or 2 ). ahhh... i remember C code... those were the days ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[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 :)
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.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JK in TC 4.0 ?
+0, and maybe a +1 some day when i have more time :) i'd just like to go on record here as saying the tomcat 4 connector for ajp/mod_jk in j-t-c is somewhat incomplete. when i last had time to play with it, it was functional, but not what i would call efficient :) but, having people know about it and use will lead to its improvement, so that's good. -kevin. Hi, I saw people posting emails asking about running mod_jk with Tomcat 4.0 (which is the only available connector for IIS). To make things easier for everyone interested in using it, we could bundle the binaries with the release distribution. mod_webapp will stay as the default native connector, as it has better integration with Tomcat 4. The Catalina wrapper for JK supports version 1.3, and was written by Kevin Seguin. The source code for this module is in jakarta-tomcat-connectors/jk. ballot [ ] +1. Integrate the mod_jk JARs with the Tomcat 4 distributions. I'll help testing / maintaining it. [ ] +0. Good idea. [ ] -0. Bad idea. [ ] -1. No, because: /ballot My vote: +1 (I'll update the build scripts, tag the j-t-c/util and j-t-c/jk repositories). Remy
RE: FW: configuration of mod_jk and tomcat-4.0
There are documents for using tomcat-4.0 with mod_jk?
Those would be very useful.
The only thing that is Tomcat-4-specific is the Connector
entry, which
is documented in jk/README.txt in the jakarta-tomcat-connectors
repository. All of the configuration files for JK are,
AFAIK, the same as
for using it with Tomcat 3.x.
They don't seem to be in the jakarta-tomcat-connectors CVS
repository, nor
could I find
them from the latest-and-greatest documentation for tomcat.
Contributions gratefully accepted :-).
Incidentally, I have the ajp.jar compiled, and in
${CATALINA_HOME}/server/lib,
(the tomcat-util.jar, as well), and I have the Connector
configured to use
org.apache.ajp.tomcat4.Ajp13Connector, but it is unclear
what Engine to use
(do I have to have an engine?).
At any rate, pointers to the location of thse docs would be
very useful
-- and thanks in advance.
- Jesse Farley
Henri, JF, this goes inside the Tomcat-Standalone service,
along with
the 8080 and 8443 connectors, right? If so it will use the standard
Engine implementation.
that is correct.
-kevin.
RE: [VOTE] New commiter Ryan Bloom
I would like to propose Ryan Bloom as commiter in Tomcat, and particulary on jakarta-tomcat-connector. Ryan is one of the dev leader in Apache 2.0 and contributed many patch for both mod_jk and mod_webapp, showing us that connectors avoid politics :) Vote, please +1
RE: isapi_redirect.dll
see the following: http://jakarta.apache.org/site/binindex.html i believe what you are looking for is this: http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.2.3/bin/win32/i38 6/ -Original Message- From: Golash Rahul [mailto:[EMAIL PROTECTED]] Sent: Monday, August 27, 2001 7:07 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: isapi_redirect.dll Hi there, Where can i find the isapi_redirect.dll which is required to redirect the requests to tomcat server while using IIS Web server as a front server for the Servlets on WinNT. Please acknowledge soon. with best regards rahul golash ___ SIEMENS Siemens Information Systems Ltd No 84, Keonics Electronics City Hosur Road, Bangalore 561 229 Rahul Golash mailto:[EMAIL PROTECTED] Systems Engineer *: +91 80 809 1288 Fax: +91 80 852 1119 ___
jakarta-tools/javac.jar
does anybody know if it is legal to redistribute this jar file? if it is legal to redistribute this jar, but not tools.jar, why? thanks for any info, -kevin.
tomcat 4 and CLIENT-CERT auth (maybe) not working properly
when i attempt to use CLIENT-CERT auth with the tomcat 4 manager webapp, tomcat appears to still be looking for basic auth credentials. for example, if i change web.xml in the manager webapp to look like this: --- snip --- security-constraint web-resource-collection web-resource-nameEntire Application/web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint !-- NOTE: This role is not present in the default users file -- role-name*/role-name /auth-constraint /security-constraint login-config auth-methodCLIENT-CERT/auth-method /login-config --- end snip --- and configure an ssl connector along with my keystore, then try to access the manager app from a client, i get a 401: HTTP/1.1 401 Cannot authenticate with the provided credentials Content-Type: text/html Date: Thu, 23 Aug 2001 20:46:21 GMT Server: Apache Tomcat/4.0-b8-dev (HTTP/1.1 Connector) Connection: close Connection: close html head titleTomcat Error Report/title brbr h1HTTP Status 401 - Cannot authenticate with the provided credentials/h1 /body /html two message appear to show up in the log when i send the request: 2001-08-23 16:09:14 CertificatesValve[/manager]: verify: SSLPeerUnverifiedException 2001-08-23 16:09:15 CertificatesValve[/manager]: expose: Exposing converted certificates which, from looking through CertificatesValve.java, seems to indicate that the client cert chain was properly verified. from reading the servlet spec, it seems that using CLIENT-CERT should not require me to do basic auth as well. did i read the spec wrong, or is this a tomcat 4 bug? thanks, -kevin.
RE: Adding another protocol
On Tue, 21 Aug 2001 [EMAIL PROTECTED] wrote: Craig, Can you point to some reference (or additional some information ) if I want to Implement a HTTP Extension on tomcat4. Thanks In Advance, Kumar. The only information that exists is in the CVS source code repository (in particular there is a couple of UML diagrams under catalina/docs/dev). Without any clue about what kind of protocol you're trying to implement, it's difficult to describe anything more precise than use the source :-). use the source, luke. - sorry, couldn't resist :) Craig
tomcat 4 request/response instrumentation
something that i've started thinking about recently is how to provide hooks in tomcat 4 so that some statistics regarding request processing time could be collected. off of the top of my head, a couple of interesting stats might be average request processing time for all contexts (or webapps) and average request processing time for each context. so, some questions: *) has anybody else considered this? *) does anybody else care about this? also, would it be possible to use a Valve to accomplish this? how are valves processed? are they stacked such that the first valve entered is the last one exited? or are they chained such that one valve is processed after the next, and once the last valve is processed, the response is sent? what i'm getting at is, could you put a valve in place such that it could always log (or send events) at the beginning of a request and right before the response is sent? tia, -kevin.
RE: tomcat 4 request/response instrumentation
also, would it be possible to use a Valve to accomplish this? Yes... how are valves processed? are they stacked such that the first valve entered is the last one exited? Correct. or are they chained such that one valve is processed after the next, and once the last valve is processed, the response is sent? Nope... See how the invoke() method works... what i'm getting at is, could you put a valve in place such that it could always log (or send events) at the beginning of a request and right before the response is sent? In TC4.0 valve are more-or-less like loggers. So if you put down a valve at the bottom of your Engine (the first root component in the component stack of Catralina), you'll end up intercepting all requests coming from the connectors... :) a valve can choose to not invoke the next valve by not calling context.invokeNext(), right? so, this would be guaranteed to work only if the statistic valve was the first valve, right? thanks for the info :)
RE: cvs commit: jakarta-tomcat-service/winnt/supcalls_nt vdenv.c
it sounds like cygwin is required for this to run. is this true? is it only because jsvc depends on it? thanks! It creates the registry values needed for the environment to start jsvc.exe JAKARTA_HOME CYGWIN (You have to set it to your cygwin directory home). JAVA_HOME (You have to set it to your JAVA_HOME directory). HOSTNAME (not yet used) HOSTPORT (not yet used) I use regedit to modify these values. 5 - Using the explorer go to profiles/allusers/program/startup and add a link to vdmoniadm.exe. 6 - Reboot the machine and logon. You should see a nice icon in the System Task-bar indicating that the Java service is running. A right click on the icon calls a small menu. Restart: (not yet implemented). Configure: (not yet implemented). Stop: Stops the java service. It is still a work in progress and blabla... Have fun...
[patch] small enhancement to JikesJavaCompiler
the attached patch makes JikesJavaCompiler output error information in a
format that can be parsed so that the information shows up in the browser.
basically, the patch just adds +E to the jikes command line options so that
errors are listed in emacs form.
Index: jasper/src/share/org/apache/jasper/compiler/JikesJavaCompiler.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JikesJavaCompiler.java,v
retrieving revision 1.4
diff -u -r1.4 JikesJavaCompiler.java
--- jasper/src/share/org/apache/jasper/compiler/JikesJavaCompiler.java 2001/02/08
13:37:54 1.4
+++ jasper/src/share/org/apache/jasper/compiler/JikesJavaCompiler.java 2001/08/08
+15:04:30
@@ -162,6 +162,7 @@
-classpath, quote + classpath + MicrosoftClasspath + quote,
-d, quote + outdir + quote,
-nowarn,
++E,
quote + source + quote
};
} else {
@@ -170,6 +171,7 @@
//XXX - add encoding once Jikes supports it
-classpath, quote + classpath + MicrosoftClasspath + quote,
-nowarn,
++E,
quote + source + quote
};
}
RE: [tomcat 4] using jikes to compile jsp's
so, i have two fixes to the problem mentioned below, and i wanted to run
them by somebody...
both fixes involve normalizing the paths that make up the classpath by
essentially passing them through File objects. the big difference is where
this normalization takes place.
one place to do it is in WebappLoader.setClassPath(). the other is in
JikesJavaCompiler.setClasspath().
attached are the diffs.
does anyone have an opinion and/or care about this?
tia for any input :)
-kevin.
has anybody tried using jikes to compile jsp's with tomcat 4
on windows
recently? i have. it barfed :)
basically what's happening is the classpath is getting messed
up. more
specifically, the entry in the classpath that points at
WEB-INF/classes/ is
getting messed up. the classpath ends up looking like this:
...;/c:/tomcat/webapps/myWebapp/WEB-INF/classes/;...
it's the beginning / that appears to be screwing jikes up.
apparently
javac can handle this kind of path, but jikes can't.
it looks like the classpath for jsp's is being set in
WebappLoader.setClasspath(), which get's respositories (which
are URL's)
from an instance of WebappClassLoader. then, for URL's that
are of the
file scheme, it pulls of the file part and adds this to the
classpath. in
the case of the above example, one of these URL's will be
file:/c:/tomcat/webapps/myWebapp/WEB-INF/classes/.
i can think of some potential hacks... but i was hoping
someone who knows
this code better would have some ideas on how this might be
fixed or worked
around :) or, is this a problem with jikes itself?
tia,
-kevin.
Index: catalina/src/share/org/apache/catalina/loader/WebappLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappLoader.java,v
retrieving revision 1.12
diff -u -r1.12 WebappLoader.java
--- catalina/src/share/org/apache/catalina/loader/WebappLoader.java 2001/07/22
20:25:10 1.12
+++ catalina/src/share/org/apache/catalina/loader/WebappLoader.java 2001/08/08
+20:38:42
@@ -1030,9 +1030,9 @@
for (int i = 0; i repositories.length; i++) {
String repository = repositories[i].toString();
if (repository.startsWith(file://))
-repository = repository.substring(7);
+repository = new File(repository.substring(7)).toString();
else if (repository.startsWith(file:))
-repository = repository.substring(5);
+repository = new File(repository.substring(5)).toString();
else if (repository.startsWith(jndi:))
repository =
servletContext.getRealPath(repository.substring(5));
Index: jasper/src/share/org/apache/jasper/compiler/JikesJavaCompiler.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JikesJavaCompiler.java,v
retrieving revision 1.4
diff -u -r1.4 JikesJavaCompiler.java
--- jasper/src/share/org/apache/jasper/compiler/JikesJavaCompiler.java 2001/02/08
13:37:54 1.4
+++ jasper/src/share/org/apache/jasper/compiler/JikesJavaCompiler.java 2001/08/08
+20:38:42
@@ -66,6 +66,7 @@
import java.io.IOException;
import java.io.File;
import java.io.ByteArrayOutputStream;
+import java.util.StringTokenizer;
/**
* A Plug-in class for specifying a 'jikes' compile.
@@ -110,7 +111,17 @@
* Set the class path for the compiler
*/
public void setClasspath(String classpath) {
- this.classpath = classpath;
+StringBuffer buf = new StringBuffer(classpath.length());
+StringTokenizer tok = new StringTokenizer(classpath,
+ File.pathSeparator);
+while (tok.hasMoreTokens()) {
+String token = tok.nextToken();
+File file = new File(token);
+ buf.append(file.toString());
+buf.append(File.pathSeparator);
+}
+
+this.classpath = buf.toString();
}
/**
@@ -162,6 +173,7 @@
-classpath, quote + classpath + MicrosoftClasspath + quote,
-d, quote + outdir + quote,
-nowarn,
++E,
quote + source + quote
};
} else {
@@ -170,6 +182,7 @@
//XXX - add encoding once Jikes supports it
-classpath, quote + classpath + MicrosoftClasspath + quote,
-nowarn,
++E,
quote + source + quote
};
}
[tomcat 4] using jikes to compile jsp's
has anybody tried using jikes to compile jsp's with tomcat 4 on windows recently? i have. it barfed :) basically what's happening is the classpath is getting messed up. more specifically, the entry in the classpath that points at WEB-INF/classes/ is getting messed up. the classpath ends up looking like this: ...;/c:/tomcat/webapps/myWebapp/WEB-INF/classes/;... it's the beginning / that appears to be screwing jikes up. apparently javac can handle this kind of path, but jikes can't. it looks like the classpath for jsp's is being set in WebappLoader.setClasspath(), which get's respositories (which are URL's) from an instance of WebappClassLoader. then, for URL's that are of the file scheme, it pulls of the file part and adds this to the classpath. in the case of the above example, one of these URL's will be file:/c:/tomcat/webapps/myWebapp/WEB-INF/classes/. i can think of some potential hacks... but i was hoping someone who knows this code better would have some ideas on how this might be fixed or worked around :) or, is this a problem with jikes itself? tia, -kevin.
RE: ISAPI redirector
the code is all in cvs. you can browse the repositories from here: http://jakarta.apache.org/site/cvsindex.html see these: jakarta-tomcat-connectors/jk/native/ jakarta-tomcat/src/native/ -kevin. I searched the archives for this list and found a few references to the Visual Studio file that goes with the isapi_redirect.dll however I couldn't find them anywhere. Does anybody know how to get the source code for isapi_redirect.dll (the workspace file or just the .c or .cpp files)?
RE: Standalone SSL Problem (was: Re: [DOC] TC4 Status)
i have seen this. little background first... i had some webapps that needed to use jsse, plus catalina needed it for https. so, i figured i'd put the jsse jars somewhere in the tc4 dist tree so that both the webapps and catalina could find them. i believe that was $TC4_HOME/common/lib. well, long story short, that barfed and i saw errors like the stack trace you saw. i got rid of the problem by taking the jsse jars out of the tc4 dist tree, and putting them into the ext dir under the jre installation, plus adding the proper line to $JAVA_HOME/jre/lib/security/java.security. Starting service Tomcat-Standalone Apache Tomcat/4.0-b6 initProxy: java.security.NoSuchAlgorithmException: Class com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext not a SSLContext java.security.NoSuchAlgorithmException: Class com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext not a SSLContext at com.sun.net.ssl.b.a([DashoPro-V1.2-120198]) at com.sun.net.ssl.SSLContext.getInstance([DashoPro-V1.2-120198]) at org.apache.catalina.net.SSLServerSocketFactory.initProxy(SSLSe rverSocketFactory.java:385) at org.apache.catalina.net.SSLServerSocketFactory.initialize(SSLS erverSocketFactory.java:328) at org.apache.catalina.net.SSLServerSocketFactory.createSocket(SS LServerSocketFactory.java:281) at org.apache.catalina.connector.http.HttpConnector.open(HttpConn ector.java:905) at org.apache.catalina.connector.http.HttpConnector.start(HttpCon nector.java:1078) at org.apache.catalina.core.StandardService.start(StandardService .java:360) at org.apache.catalina.core.StandardServer.start(StandardServer.java:458) at org.apache.catalina.startup.Catalina.start(Catalina.java:737) at org.apache.catalina.startup.Catalina.execute(Catalina.java:657) at org.apache.catalina.startup.Catalina.process(Catalina.java:178) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:202) Catalina.start: LifecycleException: HttpConnector[8443].open: java.io.IOException: java.security.NoSuchAlgorithmException: Class com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext not a SSLContext LifecycleException: HttpConnector[8443].open: java.io.IOException: java.security.NoSuchAlgorithmException: Class com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext not a SSLContext at org.apache.catalina.connector.http.HttpConnector.start(HttpCon nector.java:1080) at org.apache.catalina.core.StandardService.start(StandardService .java:360) at org.apache.catalina.core.StandardServer.start(StandardServer.java:458) at org.apache.catalina.startup.Catalina.start(Catalina.java:737) at org.apache.catalina.startup.Catalina.execute(Catalina.java:657) at org.apache.catalina.startup.Catalina.process(Catalina.java:178) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:202) - Root Cause - java.io.IOException: java.security.NoSuchAlgorithmException: Class com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext not a SSLContext at org.apache.catalina.net.SSLServerSocketFactory.initProxy(SSLSe rverSocketFactory.java:409) at org.apache.catalina.net.SSLServerSocketFactory.initialize(SSLS erverSocketFactory.java:328) at org.apache.catalina.net.SSLServerSocketFactory.createSocket(SS LServerSocketFactory.java:281) at org.apache.catalina.connector.http.HttpConnector.open(HttpConn ector.java:905) at org.apache.catalina.connector.http.HttpConnector.start(HttpCon nector.java:1078) at org.apache.catalina.core.StandardService.start(StandardService .java:360) at org.apache.catalina.core.StandardServer.start(StandardServer.java:458) at org.apache.catalina.startup.Catalina.start(Catalina.java:737) at org.apache.catalina.startup.Catalina.execute(Catalina.java:657) at org.apache.catalina.startup.Catalina.process(Catalina.java:178) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:202) Stopping service Tomcat-Standalone
RE: cvs commit: jakarta-tomcat-service/java/org/apache/service Service.java
[EMAIL PROTECTED] at [EMAIL PROTECTED] wrote:
[...]
public interface Service {
public void load(ServiceContext context) throws Exception;
public void start() throws Exception;
public void stop() throws Exception;
}
I keep going back and forth between two ideas: the first one
is the above
one, where a service is simply tied to the JVM process.
Basically, when the JVM process is created, load(...) then start() are
called, and at shutdown stop() is called.
Another idea would be this one:
public interface Service {
public void init(ServiceContext context) throws Exception;
public void start() throws Exception;
public void stop() throws Exception;
public void destroy() throws Exception;
}
This differs from the first one _not_only_ because a new
method is added,
but also because the lifecycle of a Service is different: when the JVM
process is created init() is called (instead of load, but
it's the same
shit), destroy() is called before the VM process is shut
down, but start()
and stop() simply imply that a Service could be started and
stopped many
times within the life of the JVM process...
So, now I'm stuck. Which one do you think is better (lately, I'm more
oriented towards the second approach!)
Pier
i kind of like the second approach.
i like the idea, for example, of being able to tweak a config file, then
restart a service without having to restart the entire vm.
also, it has nice symmetry with the servlet api :)
RE: Sources in Binary Distributions
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] [...] For Tomcat 4, what do folks think of omitting the sources from the binary distribution? This would knock the size of the binary distributions down by around 2 megabytes (which I'm sure people would also appreciate). +1 And also update the build.xml to omitt the sources when compiling with target dist. ++1
RE: Ajp13Connector.java initialize missing
Hi, Due to the changes in catalina/src/share/org/apache/catalina/Connector.java mod_jk does not compile with Tomcat 4.0b7-dev. Should I fix it? that'd be great :)
RE: Separating Service code from Tomcat 4.0
ME BIG DOPE :) :) :) There are TWO Win32 Service implementations... I thought Joe and Elijah were working on the same code :) :) :) But THEY'RE NOT! (Sometimes I'm just so fuckin' stupid! :) On a very rough analysis, Elijah's JavaService is better as it uses JNI, but on the other hand, Joe's TomcatService is better because the sources are way simpler, even though it uses the batch files... Ok, but JavaService looks perfect to me : - Uses JNI indeed - Service installation / removal works great - Pipes the out and the err of the JVM process into logs files in CATALINA_HOME/logs (good) - Logs stop / start / trouble to the NT event log - Very generic fwiw, i agree with remy. i took a (quick) look at JavaService, and it seems to be ideal.
RE: Separating Service code from Tomcat 4.0
Ok, but JavaService looks perfect to me : - Uses JNI indeed - Service installation / removal works great - Pipes the out and the err of the JVM process into logs files in CATALINA_HOME/logs (good) - Logs stop / start / trouble to the NT event log - Very generic fwiw, i agree with remy. i took a (quick) look at JavaService, and it seems to be ideal. Ok, wanna help out to integrate the whole kit'n kaboodle with the Service code we have? cheeky ;) but seriously, i'd love to. very low on spare time, tho, so i wouldn't be able to make any guarantees :)
RE: Post B6 modifications...
http://www.alexandriasc.com/software/JavaService/license.html It's a post-2000 BSD... We don't have to alter the copyright, but we can included it without any other legal matter... Probably the best would be to start modifying their sources and update them to our model, while, at the same time, asking them to donate the code :) How does it sound? Pier +1.
RE: t4 - jasper go boo boo
you need a new servlet.jar. update and build jakarta-servletapi-4. -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Friday, July 20, 2001 4:50 PM To: tomcat-dev Subject: t4 - jasper go boo boo I just did a fresh cvs update, ant clean, ant and I get this... -jon [176][ ~/checkout/jakarta-tomcat-4.0 ]% ant clean Buildfile: build.xml clean: build-clean: dist-clean: clean: build-clean: dist-clean: clean: build-clean: dist-clean: clean: build-clean: dist-clean: clean: BUILD SUCCESSFUL Total time: 2 seconds [177][ ~/checkout/jakarta-tomcat-4.0 ]% ant Buildfile: build.xml deploy-prepare: [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build deploy-static: deploy-main: [echo] Target: Catalina - Deploy... build-prepare: [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/b in [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/c lasses [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/c onf [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/l ib [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/c ommon [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/c ommon/lib [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/s erver [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/s erver/lib copy-jaxp-jar: [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu ild/server/lib build-static: [copy] Copying 9 files to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/b uild/bin [copy] Copying 5 files to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/b uild/conf [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu ild/common/lib [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu ild/common/lib [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu ild/server/lib [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/bu ild/server/lib build-main: [javac] Compiling 278 source files to /Users/jon/checkout/jakarta-tomcat-4.0 /catalina/build/classes [copy] Copying 26 files to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/ build/classes [jar] Building jar: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/ bin/bootstrap.jar [jar] Building jar: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/ common/lib/naming.jar [jar] Building jar: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/ common/lib/resources.jar [jar] Building jar: /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/ lib/namingfactory.jar deploy-prepare: [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/bin [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/conf [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/lib [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/logs [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/common [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/common/lib [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/server [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/server/lib [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/build/work deploy-static: [copy] Copying 10 files to /Users/jon/checkout/jakarta-tomcat-4.0/build/bin [copy] Copying 5 files to /Users/jon/checkout/jakarta-tomcat-4.0/build/conf [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/build/lib [copy] Copying 4 files to /Users/jon/checkout/jakarta-tomcat-4.0/build/comm on/lib [copy] Copying 3 files to /Users/jon/checkout/jakarta-tomcat-4.0/build/serv er/lib deploy-main: [jar] Building jar: /Users/jon/checkout/jakarta-tomcat-4.0/build/server/li b/catalina.jar [jar] Building jar: /Users/jon/checkout/jakarta-tomcat-4.0/build/server/li b/warp.jar deploy: [echo] Target: Jasper - Deploy... build-prepare: [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/jasper/build [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/jasper/build/bin [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/jasper/build/cla sses [mkdir] Created dir: /Users/jon/checkout/jakarta-tomcat-4.0/jasper/build/lib copy-jaxp-jar: [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/jasper/buil d/lib build-static: [copy] Copying 5 files to
Re: Tomcat 4 installer - testers needed
Or we can assume that java.exe is in the user's path. Jasper will need JAVA_HOME to run, though, to be able to use javac. kind of an unrelated question, but ... is there a jar file or something that can be distributed with tomcat that contains the compiler stuff so that only the jre is needed, not the jdk? i think i've heard you cannot distribute tools.jar (where i think the compiler is). -kevin.
Re: t4 - status check
What is the status of T4? I haven't seen a huge amount of commits from Craig and Remy recently Did you hear about Sun's shutdown last week ? ;-) no ... :) what is this all about ??
Re: problem with mod_webapp
jeez... it's been a while since i've used ajp13 with tomcat 4 :) if memory serves... you want to add an ajp13 connector as a child of a service, e.g.: Service name=Tomcat-Standalone Connector className=org.apache.ajp.tomcat4.Ajp13Connector port=8009 acceptCount=10 debug=0/ ... GOMEZ Henri wrote: i tried putting a Host element underneath the Engine but it didn't like that at all. i think this must be wrong since i'm trying to associate an Ajp13Connector with a WarpEngine. how should this be configured? sorry, i've not been able to find any docs for this configuration. Hi Donald, Your best friend here is Kevin Seguin who does the AJP13 port to TC 4.0 :)
Re: [J-T-C] PGP Keys
so, i don't yet have a pgp key. what is the right way to generate my public/secret key pair? pgp -kg?? RSA or DSS/DH?? thanks :) GOMEZ Henri wrote: I just added a file in J-T-C, called KEYS. To follow the Apache HTTPD team, and others jakarta and xml projects. Could I ask you, J-T-C developpers, to add your PGP KEYS ? Thanks - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: problem with mod_webapp
Hi Kevin, Are you interested to update the connector to use Ajp14 ( in backward compat mode and/or ajp14 mode ) ? I think I found both short term and long term solutions for the config issue ( well, it seems mod_jk supports the same 'autoconfig' mode as mod_webapp - and it did that since the beginning, all it need is a bit of testing and some small improvements ). The big issue is if I'll do that for Ajp14 or should I do it for Ajp13 also ( i.e. a bit more work ). More details soon, I'm sorting out few more issues. yeah, i'd be interested in updating the ajp connector for tomcat 4 do ajp14, if i could find the time ;-) i'm not sure i see the benefit in making ajp13 support autoconfig -- probably not worth the effort. probably a better use of time to concentrate on ajp14. just my $0.02 :)
Re: problem with mod_webapp
[EMAIL PROTECTED] wrote: On Fri, 29 Jun 2001, kevin seguin wrote: yeah, i'd be interested in updating the ajp connector for tomcat 4 do ajp14, if i could find the time ;-) That's the fun of doing open source... heh heh :) i'm not sure i see the benefit in making ajp13 support autoconfig -- probably not worth the effort. probably a better use of time to concentrate on ajp14. just my $0.02 :) Well, some changes are needed in ajp13 - i.e. disable the current broken system, do just context mapping as webapp, and make sure manual override works. The current generated configs don't deal with security, etc - and that means not compiant with the spec. gotcha. that makes sense. Anything advanced will go into 14 ( as long as there's hope to see the tomcat4 connector updated ) there's always hope, just no promises ;-) but seriously, the tomcat4 connector needs a bunch of work anyway, to make it more efficient. when i get to that, it would be a good time to do the ajp14 stuff.
Re: mod_jk configuration
2. Stop generating the current set of files but only uri_workers.properties ( which is equivalent with mount directives, only simpler and consistent for all supported web servers ) a big +1 on using one common configuration mechanism across web servers !!!
Re: problem with mod_webapp
use a non-threaded apr with apache 1.3. Donald Ball wrote: hey guys. i'm trying to get the latest mod_webapp from cvs to work with the latest apr from cvs and apache-1.3.12. i'm getting this error when i try to test the configuration: [root@chngw lib]# apachectl configtest Syntax error on line 41 of /usr/local/apache/conf/httpd.conf: Cannot load /usr/local/apache/libexec/mod_webapp.so into server: /usr/local/lib/libapr.so.0: undefined symbol: pthread_create any idea what's going on? it's a redhat-6.2 box with kernel-2.2.18 and glibc-2.1.3-22. apr built cleanly with no errors or warnings. - donald
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat33Ajp14Interceptor.java
[EMAIL PROTECTED] wrote: On Sun, 24 Jun 2001, kevin seguin wrote: i've been thinking about this, and, well, isn't this BaseRequest you're talking about kind of what org.apache.coyote.Request is? does it make sense to have two of these kinds of objects hanging around? is o.a.c.Request roughly equivalent to core.Request in tomcat 3?? Certainly not for the second part - the core.Request in tomcat3 has a lot of tomcat3-specific code ( Container, ContextManager, calls to hooks to get special info like encoding, etc ). The BaseRequest ( or o.a.c.Request ) is focused on the basic information associated with a request, as received by the protocol adapter. For the first part - that's true, AjpRequest is very similar in goal with o.a.c.Request ( thanks to the refactoring you did :-). As I said, I like o.a.coyote, but right now my goal is to see Ajp14 working, and using the existing (working) AjpRequest is easier. Also, coyote has more than the base request - I would let this settle down. i hear that :) my immediate goal is ajp13 for tomcat 4 :) i've checked in an intial version of BaseRequest. it may need some further work... -kevin.
[jtc - jk] jk_version.h
so, forgive me if this is a stupid question, but... how is jk_version.h generated on windows? do i need to install cygwin stuff and run buildconf.sh/configure? thanks. -kevin.
Re: Connectors in Nightly builds?
my Apologies, I'm referring to the Tomcat 4 nightly builds. Recent downloads of the source archives for tomcat 4 lacks the connector sub-directory and corresponding source files. I'm particularly interested in the mod_webapp stuff but, of course, wouldn't mind a version of mod_jk that worked with tomcat 4 ;-) mod_webapp stuff has been moved to jakarta-tomcat-connectors. there is also a working version of ajp13 for tomcat 4 there as well. -Thom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, June 25, 2001 3:17 PM To: [EMAIL PROTECTED] Subject: Re: Connectors in Nightly builds? On Mon, 25 Jun 2001, Thom Park wrote: Hi Does anyone have an E.T.A. on when the connectors will return to the nightly builds and/or when they will return to being included in the nighty source drops? Which connectors :-) ? If you are talking about the native mod_jk/mod_webapp - I didn't know they were ever built nightly. If you are talking about tomcat3.3 - the nightly build is (almost) back, probably tonight I'll fix the last problem. The old connectors are still there, the new connector ( ajp14 and the improved mod_jk ) is in j-t-c. Costin
Re: [jtc] tabs policy??
GOMEZ Henri wrote: I'm using tab = 4 so +1 there. it's important to make the distinction between indent level and number of spaces per tab -- they are totally different. i'm for 4 space indent level, tabs set to 8 spaces (the standard). tabs set to 4 spaces is bad. when some people use 4 space tabs, and some use 8, and there are tabs in source code, you're just asking for unreadable code. When you take a look in Apache projects, native and java, you could find many sources with spaces and many with tab(4). 4 space tabs, or 4 space indent level?? - 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: Saturday, June 23, 2001 2:25 AM To: [EMAIL PROTECTED] Subject: Re: [jtc] tabs policy?? Here we go... ;-) I like tabs set to four spaces, tabs in source rather than spaces and opening braces on a new line. How evil does that make me? Actually I was just wondering the other day how easy it would be to do smart de-tabbing on source -- i.e. how easily can you infer the original tab size given some arbitrary source file. Of course it's easy enough for a human, but how much syntax awareness would you need to do it automagically? kevin seguin wrote: so, is there a tabs policy in jakarta? like the number of spaces per tab (4 vs. 8), of no tabs in source code? i ask because i just got the latest jtc source, and when i open up some of the files in emacs (in which i have tab width set to 8 spaces), some lines are indented 4 spaces, and some 8. what it looks like is someone used an editor with tabs configured to be 4 spaces, but insert tab characters rather than spaces. anyway, it's quite unreadable, so that why i ask ;) (i hope this doesn't start a war ;-)) -- Andy Armstrong, Tagish
Re: [jtc] tabs policy??
It just mean that stupid programmers decided it's easier to add a panel that changes the number of spaces equivalent with TAB instead of implementing code that uses spaces for indentations 8, and replaces 8 spaces with a tab symbol. so, the programmers who wrote emacs are *not* stupid, 'cause emacs can do exactly this ;-) if all the world used emacs... oh-oh here we go ... ;-)
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java
[EMAIL PROTECTED] wrote: costin 01/06/24 14:17:13 Modified:jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java Log: Fixes for the code move. One big missing chunk is the adapter between o.a.ajp.AjpRequest and tomcat33 request ( similar with the one for tomcat4 ). I'm working on this. hey costin, one of the things i've been planning on doing is changing o.a.ajp.AjpRequest to make use of o.a.coyote.Request. basically, wrap Request in AjpRequest. does this conflict with your plans?
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java
kevin seguin wrote: [EMAIL PROTECTED] wrote: costin 01/06/24 14:17:13 Modified:jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java Log: Fixes for the code move. One big missing chunk is the adapter between o.a.ajp.AjpRequest and tomcat33 request ( similar with the one for tomcat4 ). I'm working on this. hey costin, one of the things i've been planning on doing is changing o.a.ajp.AjpRequest to make use of o.a.coyote.Request. basically, wrap Request in AjpRequest. does this conflict with your plans? actually, i take that back. i don't think i'm going to do that yet... AjpRequest will stay as is for now (unless someone else has grander plans :))
