costin 02/05/26 00:13:02
Modified:jk/java/org/apache/jk/apr AprImpl.java
Log:
- removed the mutex code, the normal invocation mechanism will be used ( i.e.
the ajp 'bridge' ).
- cleanup a bit the unix socket, preparing for the removal ( again the same
mechanism will be
costin 02/05/26 00:13:59
Modified:jk/java/org/apache/jk/common ChannelUn.java JniHandler.java
Log:
Update the unix socket channel.
Make sure the endpoint is initialized ( thanks Nacho )
Revision ChangesPath
1.18 +6 -9
costin 02/05/26 00:30:01
Modified:jk/native2/common jk_channel_apr_socket.c jk_channel_jni.c
jk_channel_socket.c jk_channel_un.c jk_workerEnv.c
Log:
Moved channels to use the init() method in jk_bean.
( all jk components will eventually be useable from
costin 02/05/26 00:31:12
Modified:jk/native2/include jk_channel.h jk_workerEnv.h
Log:
Remove the duplicated init method in channel.
The AJP13 callback ( used in JNI mode ) that was supposed to be use
by the unix channel should work with all channels.
Revision Changes
costin 02/05/26 00:33:49
Added: jk/native2/common jk_channel.c
Log:
Common dispatcher for all channels - allow any jk channel to be called by
the JNI code.
This is not yet completed, but will reduce the work in 1/2, since the
same code will be used on both sides and
costin 02/05/26 00:38:17
Modified:jk/native2/jni jk_jni_aprImpl.c org_apache_jk_apr_AprImpl.h
Log:
- removed code we don't need. ( creating and using directly the apr pools
is overkill and dangerous, things are better handled by keeping them
in the execution context -
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
jfclere 02/05/26 14:35:44
jakarta-tomcat-connectors/jk/xdocs - New directory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jfclere 02/05/26 14:36:07
jakarta-tomcat-connectors/jk/xdocs/images - New directory
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jfclere 02/05/26 14:43:36
Modified:jk build.xml
Log:
Add the tasks to build documentation for xml files.
Revision ChangesPath
1.41 +56 -0 jakarta-tomcat-connectors/jk/build.xml
Index: build.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9430.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9430.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Thanks Remy! This is a better solution.
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, May 25, 2002 5:00 PM
Subject: cvs commit:
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi
SSIServlet.java SSIServletExternalResolver.java
remm
On Fri, 24 May 2002, Kin-Man Chung wrote:
My proposal to solving this problem is to generate codes for a tag
handler (including its body) to a separate method. This is only feasible
if the tag action element and its body does not include any scripting
elements. The current trend (in the
On Mon, 27 May 2002, Denis Benoit wrote:
1. In the generated page, there is a lot of consecutive:
out.write(some string);
out.write(another string);
and so on.
Why don't we merge all these consecutive strings together?
out.write(some string\nanother
16 matches
Mail list logo
