Re: [ANNOUNCEMENT] JK2-2.0.2 released
Henri Gomez wrote: Mladen Turk wrote: Hi to all, JK2 2.0.2 has been released and is available at : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v 2.0.2/ For now binaries are available for WIN32 only: linux binaries and rpms to be released tomorrow ;) While making the linux binaries, for Apache 2.0.43, I see that jkjni.so are not generated, only jkjni.a and jkjni.la ? What's the problem ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs/common AJPv13.xml
jfclere 2002/11/28 00:52:48 Modified:jk/xdocs/common AJPv13.xml Log: Add the max length of AJP data buffer (that is implementation) and some words about chunking. Revision ChangesPath 1.4 +9 -6 jakarta-tomcat-connectors/jk/xdocs/common/AJPv13.xml Index: AJPv13.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/common/AJPv13.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- AJPv13.xml20 Sep 2002 21:35:31 - 1.3 +++ AJPv13.xml28 Nov 2002 08:52:48 - 1.4 @@ -608,15 +608,18 @@ subsection name=Get Body Chunk p - The container asks for more data from the request (if the body was - too large to fit in the first packet sent over). The server will send a - body packet back with an amount of data which is the minimum of the - coderequest_length/code, the maximum send body size (XXX), and the + The container asks for more data from the request (If the body was + too large to fit in the first packet sent over or when the request is + chuncked). + The server will send a body packet back with an amount of data which is + the minimum of the coderequest_length/code, + the maximum send body size (8186 (8 Kbytes - 6)), and the number of bytes actually left to send from the request body. br/ If there is no more data in the body (i.e. the servlet container is trying to read past the end of the body), the server will send back an - empty packet, whch is a body packet with a payload length of 0. + empty packet, which is a body packet with a payload length of 0. + (0x12,0x34,0x00,0x00) /p /subsection /section -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AW: euro character problem with tomcat compression Filter
And failing that perhaps cp1252 if you are a windowz kind of guy. I find this page helpful: http://czyborra.com/charsets/iso8859.html Martin On Thu, 2002-11-28 at 07:46, Torsten Fohrer wrote: sorry, iso-8859-15 -Ursprüngliche Nachricht- Von: Torsten Fohrer [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 28. November 2002 08:28 An: 'Tomcat Developers List' Betreff: AW: euro character problem with tomcat compression Filter try, to set the response encoding to 8559-15 cu Torsten -Ursprüngliche Nachricht- Von: Sergio [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 27. November 2002 21:18 An: 'Tomcat Developers List' Betreff: euro character problem with tomcat compression Filter Hí techies! I'm having problems adding the tomcat compression Filter version 4.0.3 to my webapp. Some characters (like euro symbol ) that are printed in my jsp page with a method which return a field of a MSSQLServer table, are printed with the '?' symbol. I've modified the CompressionFilter.java servlet and modified the code. Before the call of doFilter method I set the request to my encoding: request.setCharacterEncoding(iso-8859-1); chain.doFilter(request, response); But this also does not work. Any solution or idea ? Sorry for my English. Thanks, Sergio -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ANNOUNCEMENT] JK2-2.0.2 released
Henri Gomez wrote: Henri Gomez wrote: Mladen Turk wrote: Hi to all, JK2 2.0.2 has been released and is available at : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v 2.0.2/ For now binaries are available for WIN32 only: linux binaries and rpms to be released tomorrow ;) While making the linux binaries, for Apache 2.0.43, I see that jkjni.so are not generated, only jkjni.a and jkjni.la ? What's the problem ? Probably libtool. The one of the Apache 2.0.43 you are using. -- 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]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_version.h
hgomez 2002/11/28 01:50:27 Modified:jk/native/common jk_version.h Log: Follow Apache version number (like jk2), version will now be reported as : mod_jk 1.2.2-dev Revision ChangesPath 1.7 +13 -7 jakarta-tomcat-connectors/jk/native/common/jk_version.h Index: jk_version.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_version.h,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- jk_version.h 26 Nov 2002 17:14:55 - 1.6 +++ jk_version.h 28 Nov 2002 09:50:26 - 1.7 @@ -67,11 +67,11 @@ /** START OF AREA TO MODIFY BEFORE RELEASING */ #define JK_VERMAJOR 1 #define JK_VERMINOR 2 -#define JK_VERFIX 0 +#define JK_VERFIX 2 #define JK_VERSTRING1.2.2 /* Beta number */ -#define JK_VERBETA 1 +#define JK_VERBETA 0 #define JK_BETASTRING 1 /* set JK_VERISRELEASE to 1 when release (do not forget to commit!) */ #define JK_VERISRELEASE 0 @@ -82,11 +82,17 @@ #define JK_EXPOSED_VERSION_INT PACKAGE JK_VERSTRING #if ( JK_VERISRELEASE == 1 ) -#define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT -#undef JK_VERBETA -#define JK_VERBETA 255 + #define JK_RELEASE_STR JK_EXPOSED_VERSION_INT #else -#define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT -beta- JK_BETASTRING + #define JK_RELEASE_STR JK_EXPOSED_VERSION_INT -dev +#endif + +#if ( JK_VERBETA == 0 ) +#define JK_EXPOSED_VERSION JK_RELEASE_STR +#undef JK_VERBETA +#define JK_VERBETA 255 +#else +#define JK_EXPOSED_VERSION JK_RELEASE_STR -beta- JK_BETASTRING #endif #define JK_MAKEVERSION(major, minor, fix, beta) (((major) 24) + ((minor) 16) + ((fix) 8) + (beta)) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ANNOUNCEMENT] JK2-2.0.2 released
Probably libtool. The one of the Apache 2.0.43 you are using. What's the heck with libtool again ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
AW: AW: euro character problem with tomcat compression Filter
ok... but if you set response content-type to text/html; charset: iso-8859-15, pages shows correctly with euro symbols in konqueror, netscape 4, ie and so on...if you have a font that contains it. -Ursprüngliche Nachricht- Von: Martin Algesten [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 28. November 2002 10:17 An: Tomcat Developers List Betreff: Re: AW: euro character problem with tomcat compression Filter And failing that perhaps cp1252 if you are a windowz kind of guy. I find this page helpful: http://czyborra.com/charsets/iso8859.html Martin On Thu, 2002-11-28 at 07:46, Torsten Fohrer wrote: sorry, iso-8859-15 -Ursprüngliche Nachricht- Von: Torsten Fohrer [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 28. November 2002 08:28 An: 'Tomcat Developers List' Betreff: AW: euro character problem with tomcat compression Filter try, to set the response encoding to 8559-15 cu Torsten -Ursprüngliche Nachricht- Von: Sergio [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 27. November 2002 21:18 An: 'Tomcat Developers List' Betreff: euro character problem with tomcat compression Filter Hí techies! I'm having problems adding the tomcat compression Filter version 4.0.3 to my webapp. Some characters (like euro symbol ) that are printed in my jsp page with a method which return a field of a MSSQLServer table, are printed with the '?' symbol. I've modified the CompressionFilter.java servlet and modified the code. Before the call of doFilter method I set the request to my encoding: request.setCharacterEncoding(iso-8859-1); chain.doFilter(request, response); But this also does not work. Any solution or idea ? Sorry for my English. Thanks, Sergio -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ANNOUNCEMENT] JK2-2.0.2 released
Henri Gomez wrote: Probably libtool. The one of the Apache 2.0.43 you are using. What's the heck with libtool again ? Look in the build/jk2/apache2/jkjni.la Probably there is a jkjni.a instead jkjni.so there. May be you only have a libapr-0.a in your Apache 2.0.43. -- 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]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
remm2002/11/28 03:24:29
Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
Log:
- Experiment with not using the pool.
Revision ChangesPath
1.7 +4 -4
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java
Index: PoolTcpEndpoint.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- PoolTcpEndpoint.java 22 Oct 2002 09:42:48 - 1.6
+++ PoolTcpEndpoint.java 28 Nov 2002 11:24:28 - 1.7
@@ -464,7 +464,7 @@
*/
PoolTcpEndpoint endpoint;
SimplePool connectionCache;
-static final boolean usePool=true;
+static final boolean usePool=false;
public TcpWorkerThread(PoolTcpEndpoint endpoint) {
this.endpoint = endpoint;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ANNOUNCEMENT] JK2-2.0.2 released
While building with Apache-1.3 I have the problem that it only builds with apxs: cd jk/native2/server/apache13; gmake -f Makefile.apxs Trying make in jk/native2 shows that the Makefile.in was not ready for releasing: - miss libtool - miss -rpath $apache_modules_dir when making the mod_jk2.so file. Cheers Jean-frederic Mladen Turk wrote: Hi to all, JK2 2.0.2 has been released and is available at : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v 2.0.2/ For now binaries are available for WIN32 only: Changes between JK2 2.0.1 and JK2 2.0.2: * Fix the bug 14293. Thanks to Martin Kraemer for his help. [Jean-Frederic Clere] * Don't send initial chunk for chunked encoding, fix #14282 [Costin Manolache] * Fix the POST data on JNI [Mladen Turk] * Remove the deprecated message for path [Costin Manolache] * Add the regular expressions to uriMap. The regex uris are differentiated to normal one by starting with dollar ($) sign. [Mladen Turk] * Add the max_connections to the wajp13 worker. [Mladen Turk] * Add the hostMap cache [Mladen Turk] * Allow the lb:name scheme inside the [channel.xxx] [Mladen Turk] * Duplicate all global directives on each vhost that has inheritGlobals set. Directives are created using createBean only if not found. Beside directives, the webapps are duplicated to. [Mladen Turk] Regards, MT. -- 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: AW: euro character problem with tomcat compression Filter
The problem I comment, did not occurs before setting on the compressionFilter. I've changed also the request.setCharacterEncoding to iso-8859-15 and still works bad. The response object dont have a method to set the character encoding, but I can add a header: wrappedResponse.addHeader(charset,iso-8859-15) but this also dont works. How to change the character enconding that gzip uses ? Other idea ? Thx, Sergio. - Original Message - From: Torsten Fohrer [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Sent: Thursday, November 28, 2002 11:26 AM Subject: AW: AW: euro character problem with tomcat compression Filter ok... but if you set response content-type to text/html; charset: iso-8859-15, pages shows correctly with euro symbols in konqueror, netscape 4, ie and so on...if you have a font that contains it. -Ursprüngliche Nachricht- Von: Martin Algesten [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 28. November 2002 10:17 An: Tomcat Developers List Betreff: Re: AW: euro character problem with tomcat compression Filter And failing that perhaps cp1252 if you are a windowz kind of guy. I find this page helpful: http://czyborra.com/charsets/iso8859.html Martin On Thu, 2002-11-28 at 07:46, Torsten Fohrer wrote: sorry, iso-8859-15 -Ursprüngliche Nachricht- Von: Torsten Fohrer [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 28. November 2002 08:28 An: 'Tomcat Developers List' Betreff: AW: euro character problem with tomcat compression Filter try, to set the response encoding to 8559-15 cu Torsten -Ursprüngliche Nachricht- Von: Sergio [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 27. November 2002 21:18 An: 'Tomcat Developers List' Betreff: euro character problem with tomcat compression Filter Hí techies! I'm having problems adding the tomcat compression Filter version 4.0.3 to my webapp. Some characters (like euro symbol ) that are printed in my jsp page with a method which return a field of a MSSQLServer table, are printed with the '?' symbol. I've modified the CompressionFilter.java servlet and modified the code. Before the call of doFilter method I set the request to my encoding: request.setCharacterEncoding(iso-8859-1); chain.doFilter(request, response); But this also does not work. Any solution or idea ? Sorry for my English. Thanks, Sergio -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- 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]
Manager App
I'm currently using TC 4.1.12. I've been taking advantage of the fact that I can drop an XML file into the tomcat/webapps directory and have this recognized as a context. However I've just started using the manager app. It appears that when I do anything 'serious' with the manager it includes all the contexts defined inside tomcat/webapps and merges their details into tomcat/conf/server.xml. This means that if I change a context in the webapps directory those changes do not get picked up either by tomcat, or by the manager if I do a stop/start, a restart or an undeploy/deploy. I'm assuming this behaviour is a legacy of the fact that adding contexts to the 'webapps' directory is a fairly recent change to TC. I also remember seeing some discussion of the behaviour of the manager app here a little while ago. Are there any plans to change the manager so that changes to contexts declared in the webapps directory get merged back into server.xml? Thanks, Kevin Jones Developmentor www.develop.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
mod_jk-2.0.42.so
I trying to configure the Apache + JServ, but a have a problem. When the apache is started it return a error message like this: Cannot load /usr/local/www/apache/libexec/mod_jk-2.0.42.so into server: /usr/local/www/apache/libexec/mod_jk-2.0.42.so: Undefined symbol ap_hook_post_config ./apachectl startssl: httpd could not be started My apache is a 1.3.27 and i using the AJP13 connector and tomcat 4.1.12. Tanks, Pedro Igor
Re: mod_jk-2.0.42.so
Pedro Igor Craveiro e Silva wrote: I trying to configure the Apache + JServ, but a have a problem. When the apache is started it return a error message like this: Cannot load /usr/local/www/apache/libexec/mod_jk-2.0.42.so into server: /usr/local/www/apache/libexec/mod_jk-2.0.42.so: Undefined symbol ap_hook_post_config ./apachectl startssl: httpd could not be started My apache is a 1.3.27 and i using the AJP13 connector and tomcat 4.1.12. Tanks, mod_jk-2.0.42.so is for Apache 2.0.42 and later. For Apache 1.3.27 use instead mod_jk-1.3-eapi.so (since you've got apache+mod_ssl) Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ANNOUNCEMENT] JK2-2.0.2 released
jean-frederic clere wrote: Henri Gomez wrote: Probably libtool. The one of the Apache 2.0.43 you are using. What's the heck with libtool again ? Look in the build/jk2/apache2/jkjni.la Probably there is a jkjni.a instead jkjni.so there. Yes jkjni.la and jkjni.a May be you only have a libapr-0.a in your Apache 2.0.43. No, I've got libapr.so And I've got mod_jk2.so -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Filter in Tomcat 3.3.1
Hi all, can filter be applied in Tomcat 3.3.1. did anyone try filters in tomcat3.3.1 if so please tell me the sequnce... thanks in advance Regards Laxmikanth M S Off* : 91-80-6610330 extn 1256 Res* : 91-80-5267150 http://www.sonata-software.com Coming together is the beginning, staying together is progress and working together is Success What lies behind us and what lies before us are tiny matters compared to what lies within us - Emerson * Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. * -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
AW: AW: euro character problem with tomcat compression Filter
Add the following in your jsp page.. if you get the euro sign from jdbc driver, which codepage he use? %@ page contentType = text/html; charset: iso-8859-15 % euro; -Ursprüngliche Nachricht- Von: Sergio [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 28. November 2002 12:50 An: Tomcat Developers List Betreff: Re: AW: euro character problem with tomcat compression Filter The problem I comment, did not occurs before setting on the compressionFilter. I've changed also the request.setCharacterEncoding to iso-8859-15 and still works bad. The response object dont have a method to set the character encoding, but I can add a header: wrappedResponse.addHeader(charset,iso-8859-15) but this also dont works. How to change the character enconding that gzip uses ? Other idea ? Thx, Sergio. - Original Message - From: Torsten Fohrer [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Sent: Thursday, November 28, 2002 11:26 AM Subject: AW: AW: euro character problem with tomcat compression Filter ok... but if you set response content-type to text/html; charset: iso-8859-15, pages shows correctly with euro symbols in konqueror, netscape 4, ie and so on...if you have a font that contains it. -Ursprüngliche Nachricht- Von: Martin Algesten [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 28. November 2002 10:17 An: Tomcat Developers List Betreff: Re: AW: euro character problem with tomcat compression Filter And failing that perhaps cp1252 if you are a windowz kind of guy. I find this page helpful: http://czyborra.com/charsets/iso8859.html Martin On Thu, 2002-11-28 at 07:46, Torsten Fohrer wrote: sorry, iso-8859-15 -Ursprüngliche Nachricht- Von: Torsten Fohrer [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 28. November 2002 08:28 An: 'Tomcat Developers List' Betreff: AW: euro character problem with tomcat compression Filter try, to set the response encoding to 8559-15 cu Torsten -Ursprüngliche Nachricht- Von: Sergio [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 27. November 2002 21:18 An: 'Tomcat Developers List' Betreff: euro character problem with tomcat compression Filter Hí techies! I'm having problems adding the tomcat compression Filter version 4.0.3 to my webapp. Some characters (like euro symbol ) that are printed in my jsp page with a method which return a field of a MSSQLServer table, are printed with the '?' symbol. I've modified the CompressionFilter.java servlet and modified the code. Before the call of doFilter method I set the request to my encoding: request.setCharacterEncoding(iso-8859-1); chain.doFilter(request, response); But this also does not work. Any solution or idea ? Sorry for my English. Thanks, Sergio -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk-2.0.42.so
Thakns. ... but just one more, i don´t find this mod, do you have a clue ?? Pedro Igor - Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, November 28, 2002 9:19 AM Subject: Re: mod_jk-2.0.42.so Pedro Igor Craveiro e Silva wrote: I trying to configure the Apache + JServ, but a have a problem. When the apache is started it return a error message like this: Cannot load /usr/local/www/apache/libexec/mod_jk-2.0.42.so into server: /usr/local/www/apache/libexec/mod_jk-2.0.42.so: Undefined symbol ap_hook_post_config ./apachectl startssl: httpd could not be started My apache is a 1.3.27 and i using the AJP13 connector and tomcat 4.1.12. Tanks, mod_jk-2.0.42.so is for Apache 2.0.42 and later. For Apache 1.3.27 use instead mod_jk-1.3-eapi.so (since you've got apache+mod_ssl) Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ANNOUNCEMENT] JK2-2.0.2 released
Henri Gomez wrote: jean-frederic clere wrote: Henri Gomez wrote: Probably libtool. The one of the Apache 2.0.43 you are using. What's the heck with libtool again ? Look in the build/jk2/apache2/jkjni.la Probably there is a jkjni.a instead jkjni.so there. Yes jkjni.la and jkjni.a May be you only have a libapr-0.a in your Apache 2.0.43. No, I've got libapr.so And I've got mod_jk2.so Very weird. Send me the complete output of make. -- 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: [ANNOUNCEMENT] JK2-2.0.2 released
Clere, Jean-Frederic wrote:
While building with Apache-1.3 I have the problem that it only builds
with apxs:
cd jk/native2/server/apache13; gmake -f Makefile.apxs
The next problem is that this mod_jk2.so is not ok:
+++
bash-2.03$ bin/apachectl start
Syntax error on line 224 of /export/home2/apache20/apache26/conf/httpd.conf:
Cannot load /export/home2/apache20/apache26/libexec/mod_jk2.so into server:
ld.so.1: /export/home2/apache20/apache26/bin/httpd: fatal: relocation error:
file /export/home2/apache20/apache26/libexec/mod_jk2.so: symbol
jk2_service_apache13_init: referenced symbol not found
bin/apachectl start: httpd could not be started
+++
Trying make in jk/native2 shows that the Makefile.in was not ready for
releasing:
- miss libtool
- miss -rpath $apache_modules_dir when making the mod_jk2.so file.
Find enclosed the patch to apply after the configure. (To server/apache13/Makefile).
But the produced mod_jk2.so does not work on my Solaris8 machine it cores:
+++
(/opt/SUNWspro/WS6U1/bin/sparcv9/dbx) where
current thread: t@1
=[1] strlen(0x0, 0x0, 0xfe64247c, 0x7efefeff, 0x81010100, 0xff), at 0xff1b3344
[2] _doprnt(0x0, 0xffbef914, 0x0, 0x97091, 0x0, 0xfe64248e), at 0xff202f38
[3] vsnprintf(0xffbed891, 0x7fff, 0xfe64247c, 0xffbef914, 0xfe64246d,
0x1d0), at 0xff2050ac
[4] jk2_logger_file_jkVLog(0xfe656f64, 0xffbed858, 0xffbef914, 0x1d0, 0x0,
0xfe64247c), at 0xfe62bb34
[5] jk2_logger_file_jkLog(0xa6278, 0xa7ca0, 0xfe642460, 0x1d0, 0x0,
0xfe64247c), at 0xfe62bb94
[6] jk2_uriMap_createWebapps(0xfe6555b8, 0x0, 0xaba98, 0xc4eb8, 0xfe65700c,
0xfe642460), at 0xfe634d1c
[7] jk2_uriMap_init(0xa6278, 0xa8cf8, 0x4, 0x0, 0x75736572, 0x68616e64), at
0xfe635c24
[8] jk2_workerEnv_init(0xfe6570b4, 0x0, 0xfe642e54, 0xa6700, 0xfe642e28,
0xfe6448d8), at 0xfe637e3c
[9] jk2_init(0x996d8, 0x996b0, 0x2d314, 0x1d304, 0xf, 0x25bf8), at 0xfe63e684
[10] ap_init_modules(0x996b0, 0x996d8, 0x25bf8, 0x8e800, 0x8e800, 0x7b28c),
at 0x26ee4
[11] main(0x1, 0xffbefbbc, 0xffbefbc4, 0x8e800, 0x0, 0x0), at 0x343fc
+++
Cheers
Jean-frederic
Mladen Turk wrote:
Hi to all,
JK2 2.0.2 has been released and is available at :
http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v
2.0.2/
For now binaries are available for WIN32 only:
Changes between JK2 2.0.1 and JK2 2.0.2:
* Fix the bug 14293. Thanks to Martin Kraemer for his help.
[Jean-Frederic Clere]
* Don't send initial chunk for chunked encoding, fix #14282
[Costin Manolache]
* Fix the POST data on JNI
[Mladen Turk]
* Remove the deprecated message for path
[Costin Manolache]
* Add the regular expressions to uriMap. The regex uris are
differentiated
to normal one by starting with dollar ($) sign.
[Mladen Turk]
* Add the max_connections to the wajp13 worker.
[Mladen Turk]* Add the hostMap cache
[Mladen Turk] * Allow the lb:name scheme inside the
[channel.xxx]
[Mladen Turk]
* Duplicate all global directives on each vhost that has
inheritGlobals set.
Directives are created using createBean only if not
found.
Beside directives, the webapps are duplicated to.
[Mladen Turk]
Regards,
MT.
--
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]
--- server/apache13/Makefile2002-11-28 13:14:35.0 +0100
+++ server/apache13/Makefile.ok 2002-11-28 13:13:16.991527000 +0100
@@ -7,14 +7,16 @@
EXTRA_CFLAGS=-DSOLARIS2=280 -DUSE_EXPAT -I../lib/expat-lite -xO5
EXTRA_CPPFLAGS=
JAVA_HOME=/export/home2/tomcat/j2sdk1_3_1_03
+APACHE_LIBEXEC=${APACHE_HOME}/libexec
JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS}
-JAVA_LIB=-L ${JAVA_HOME}/jre/lib/${ARCH} -L ${JAVA_HOME}/lib/${ARCH}/native_threads
+JAVA_LIB=-L${JAVA_HOME}/jre/lib/${ARCH} -L${JAVA_HOME}/lib/${ARCH}/native_threads
JK_DIR := ../..
BUILD_DIR = ${JK_DIR}/../build/jk2/apache13
#LIBTOOL=$(SHELL) $(top_builddir)/libtool
+LIBTOOL=$(SHELL) $(JK_DIR)/libtool
# It doesn't hurt if we include all
INCLUDES= -I${JK_DIR}/include \
@@ -34,7 +36,8 @@
COMPILE = $(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(ALL_INCLUDES)
SH_COMPILE = $(LIBTOOL) --mode=compile $(COMPILE) $(JK_CFLAGS)
-MOD_LINK = $(LIBTOOL) --mode=link $(CC) -module -shared $(LT_LDFLAGS) $(ALL_LDFLAGS)
$(JK_LDFLAGS)
+MOD_LINK = $(LIBTOOL) --mode=link $(CC) -avoid-version -module -rpath
+$(APACHE_LIBEXEC) $(LT_LDFLAGS) $(ALL_LDFLAGS) $(JK_LDFLAGS)
+MOD_INSTALL = $(LIBTOOL) --mode=install $(CP)
#
@@ -73,8 +76,11 @@
all: prepare ${BUILD_DIR}/mod_jk2.so
-${BUILD_DIR}/mod_jk2.so: ${COMMON_LO_FILES} ${A_LO_FILES}
- ${MOD_LINK} -o $@ $^
+${BUILD_DIR}/mod_jk2.so: ${BUILD_DIR}/mod_jk2.la
+
Re: mod_jk-2.0.42.so
Pedro Igor Craveiro e Silva wrote: Thakns. ... but just one more, i don´t find this mod, do you have a clue ?? It's next to the other one ! http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.1/bin/linux/i386/mod_jk-1.3-eapi.so -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ANNOUNCEMENT] JK2-2.0.2 released
jean-frederic clere wrote: Clere, Jean-Frederic wrote: While building with Apache-1.3 I have the problem that it only builds with apxs: cd jk/native2/server/apache13; gmake -f Makefile.apxs The next problem is that this mod_jk2.so is not ok: +++ bash-2.03$ bin/apachectl start Syntax error on line 224 of /export/home2/apache20/apache26/conf/httpd.conf: Cannot load /export/home2/apache20/apache26/libexec/mod_jk2.so into server: ld.so.1: /export/home2/apache20/apache26/bin/httpd: fatal: relocation error: file /export/home2/apache20/apache26/libexec/mod_jk2.so: symbol jk2_service_apache13_init: referenced symbol not found bin/apachectl start: httpd could not be started +++ apache13_init called in jk2 for Apache 2.0 ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ANNOUNCEMENT] JK2-2.0.2 released
Very weird. Send me the complete output of make. here it is : httpd2/lib -lcrypt -lapr-0 -lpcre -lpcreposix ../../../build/jk2/apache2/jk_jni_aprImpl.lo ../../../build/jk2/apache2/jk_channel_apr_socket.lo ../../../build/jk2/apache2/jk_channel.lo ../../../build/jk2/apache2/jk_channel_jni.lo ../../../build/jk2/apache2/jk_channel_socket.lo ../../../build/jk2/apache2/jk_channel_un.lo ../../../build/jk2/apache2/jk_config.lo ../../../build/jk2/apache2/jk_config_file.lo ../../../build/jk2/apache2/jk_endpoint.lo ../../../build/jk2/apache2/jk_env.lo ../../../build/jk2/apache2/jk_handler_logon.lo ../../../build/jk2/apache2/jk_handler_response.lo ../../../build/jk2/apache2/jk_logger_file.lo ../../../build/jk2/apache2/jk_logger_win32.lo ../../../build/jk2/apache2/jk_map.lo ../../../build/jk2/apache2/jk_md5.lo ../../../build/jk2/apache2/jk_msg_ajp.lo ../../../build/jk2/apache2/jk_mutex.lo ../../../build/jk2/apache2/jk_mutex_proc.lo ../../../build/jk2/apache2/jk_mutex_thread.lo ../../../build/jk2/apache2/jk_nwmain.lo ../../../build/jk2/apache2/jk_objCache.lo ../../../build/jk2/apache2/jk_pool_apr.lo ../../../build/jk2/apache2/jk_pool.lo ../../../build/jk2/apache2/jk_registry.lo ../../../build/jk2/apache2/jk_requtil.lo ../../../build/jk2/apache2/jk_shm.lo ../../../build/jk2/apache2/jk_signal.lo ../../../build/jk2/apache2/jk_uriEnv.lo ../../../build/jk2/apache2/jk_uriMap.lo ../../../build/jk2/apache2/jk_user.lo ../../../build/jk2/apache2/jk_vm_default.lo ../../../build/jk2/apache2/jk_worker_ajp13.lo ../../../build/jk2/apache2/jk_workerEnv.lo ../../../build/jk2/apache2/jk_worker_jni.lo ../../../build/jk2/apache2/jk_worker_lb.lo ../../../build/jk2/apache2/jk_worker_run.lo ../../../build/jk2/apache2/jk_worker_status.lo rm -fr ../../../build/jk2/apache2/.libs/jkjni.la ../../../build/jk2/apache2/.libs/jkjni.* ../../../build/jk2/apache2/.libs/jkjni.* *** Warning: This library needs some functionality provided by -lapr-0. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module jkjni. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. ar cru ../../../build/jk2/apache2/.libs/jkjni.a ../../../build/jk2/apache2/jk_jni_aprImpl.lo ../../../build/jk2/apache2/jk_channel_apr_socket.lo ../../../build/jk2/apache2/jk_channel.lo ../../../build/jk2/apache2/jk_channel_jni.lo ../../../build/jk2/apache2/jk_channel_socket.lo ../../../build/jk2/apache2/jk_channel_un.lo ../../../build/jk2/apache2/jk_config.lo ../../../build/jk2/apache2/jk_config_file.lo ../../../build/jk2/apache2/jk_endpoint.lo ../../../build/jk2/apache2/jk_env.lo ../../../build/jk2/apache2/jk_handler_logon.lo ../../../build/jk2/apache2/jk_handler_response.lo ../../../build/jk2/apache2/jk_logger_file.lo ../../../build/jk2/apache2/jk_logger_win32.lo ../../../build/jk2/apache2/jk_map.lo ../../../build/jk2/apache2/jk_md5.lo ../../../build/jk2/apache2/jk_msg_ajp.lo ../../../build/jk2/apache2/jk_mutex.lo ../../../build/jk2/apache2/jk_mutex_proc.lo ../../../build/jk2/apache2/jk_mutex_thread.lo ../../../build/jk2/apache2/jk_nwmain.lo ../../../build/jk2/apache2/jk_objCache.lo ../../../build/jk2/apache2/jk_pool_apr.lo ../../../build/jk2/apache2/jk_pool.lo ../../../build/jk2/apache2/jk_registry.lo ../../../build/jk2/apache2/jk_requtil.lo ../../../build/jk2/apache2/jk_shm.lo ../../../build/jk2/apache2/jk_signal.lo ../../../build/jk2/apache2/jk_uriEnv.lo ../../../build/jk2/apache2/jk_uriMap.lo ../../../build/jk2/apache2/jk_user.lo ../../../build/jk2/apache2/jk_vm_default.lo ../../../build/jk2/apache2/jk_worker_ajp13.lo ../../../build/jk2/apache2/jk_workerEnv.lo ../../../build/jk2/apache2/jk_worker_jni.lo ../../../build/jk2/apache2/jk_worker_lb.lo ../../../build/jk2/apache2/jk_worker_run.lo ../../../build/jk2/apache2/jk_worker_status.lo ranlib ../../../build/jk2/apache2/.libs/jkjni.a creating ../../../build/jk2/apache2/jkjni.la (cd ../../../build/jk2/apache2/.libs rm -f jkjni.la ln -s ../jkjni.la jkjni.la) /etc/httpd2/build/libtool --mode=install cp ../../../build/jk2/apache2/jkjni.la `pwd`/../../../build/jk2/apache2 cp ../../../build/jk2/apache2/.libs/jkjni.lai /home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.la cp ../../../build/jk2/apache2/.libs/jkjni.a /home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.a ranlib /home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.a chmod 644 /home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.a
Re: [ANNOUNCEMENT] JK2-2.0.2 released
Henri Gomez wrote: jean-frederic clere wrote: Clere, Jean-Frederic wrote: While building with Apache-1.3 I have the problem that it only builds with apxs: cd jk/native2/server/apache13; gmake -f Makefile.apxs The next problem is that this mod_jk2.so is not ok: +++ bash-2.03$ bin/apachectl start Syntax error on line 224 of /export/home2/apache20/apache26/conf/httpd.conf: Cannot load /export/home2/apache20/apache26/libexec/mod_jk2.so into server: ld.so.1: /export/home2/apache20/apache26/bin/httpd: fatal: relocation error: file /export/home2/apache20/apache26/libexec/mod_jk2.so: symbol jk2_service_apache13_init: referenced symbol not found bin/apachectl start: httpd could not be started +++ apache13_init called in jk2 for Apache 2.0 ? No that is apache_1.3._26. apache20 is the name of my user on this machine. Sorry for the confusion %-) -- 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: [ANNOUNCEMENT] JK2-2.0.2 released
Henri Gomez wrote: Very weird. Send me the complete output of make. here it is : httpd2/lib -lcrypt -lapr-0 -lpcre -lpcreposix ../../../build/jk2/apache2/jk_jni_aprImpl.lo ../../../build/jk2/apache2/jk_channel_apr_socket.lo ../../../build/jk2/apache2/jk_channel.lo ../../../build/jk2/apache2/jk_channel_jni.lo ../../../build/jk2/apache2/jk_channel_socket.lo ../../../build/jk2/apache2/jk_channel_un.lo ../../../build/jk2/apache2/jk_config.lo ../../../build/jk2/apache2/jk_config_file.lo ../../../build/jk2/apache2/jk_endpoint.lo ../../../build/jk2/apache2/jk_env.lo ../../../build/jk2/apache2/jk_handler_logon.lo ../../../build/jk2/apache2/jk_handler_response.lo ../../../build/jk2/apache2/jk_logger_file.lo ../../../build/jk2/apache2/jk_logger_win32.lo ../../../build/jk2/apache2/jk_map.lo ../../../build/jk2/apache2/jk_md5.lo ../../../build/jk2/apache2/jk_msg_ajp.lo ../../../build/jk2/apache2/jk_mutex.lo ../../../build/jk2/apache2/jk_mutex_proc.lo ../../../build/jk2/apache2/jk_mutex_thread.lo ../../../build/jk2/apache2/jk_nwmain.lo ../../../build/jk2/apache2/jk_objCache.lo ../../../build/jk2/apache2/jk_pool_apr.lo ../../../build/jk2/apache2/jk_pool.lo ../../../build/jk2/apache2/jk_registry.lo ../../../build/jk2/apache2/jk_requtil.lo ../../../build/jk2/apache2/jk_shm.lo ../../../build/jk2/apache2/jk_signal.lo ../../../build/jk2/apache2/jk_uriEnv.lo ../../../build/jk2/apache2/jk_uriMap.lo ../../../build/jk2/apache2/jk_user.lo ../../../build/jk2/apache2/jk_vm_default.lo ../../../build/jk2/apache2/jk_worker_ajp13.lo ../../../build/jk2/apache2/jk_workerEnv.lo ../../../build/jk2/apache2/jk_worker_jni.lo ../../../build/jk2/apache2/jk_worker_lb.lo ../../../build/jk2/apache2/jk_worker_run.lo ../../../build/jk2/apache2/jk_worker_status.lo rm -fr ../../../build/jk2/apache2/.libs/jkjni.la ../../../build/jk2/apache2/.libs/jkjni.* ../../../build/jk2/apache2/.libs/jkjni.* *** Warning: This library needs some functionality provided by -lapr-0. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module jkjni. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. ar cru ../../../build/jk2/apache2/.libs/jkjni.a ../../../build/jk2/apache2/jk_jni_aprImpl.lo ../../../build/jk2/apache2/jk_channel_apr_socket.lo ../../../build/jk2/apache2/jk_channel.lo ../../../build/jk2/apache2/jk_channel_jni.lo ../../../build/jk2/apache2/jk_channel_socket.lo ../../../build/jk2/apache2/jk_channel_un.lo ../../../build/jk2/apache2/jk_config.lo ../../../build/jk2/apache2/jk_config_file.lo ../../../build/jk2/apache2/jk_endpoint.lo ../../../build/jk2/apache2/jk_env.lo ../../../build/jk2/apache2/jk_handler_logon.lo ../../../build/jk2/apache2/jk_handler_response.lo ../../../build/jk2/apache2/jk_logger_file.lo ../../../build/jk2/apache2/jk_logger_win32.lo ../../../build/jk2/apache2/jk_map.lo ../../../build/jk2/apache2/jk_md5.lo ../../../build/jk2/apache2/jk_msg_ajp.lo ../../../build/jk2/apache2/jk_mutex.lo ../../../build/jk2/apache2/jk_mutex_proc.lo ../../../build/jk2/apache2/jk_mutex_thread.lo ../../../build/jk2/apache2/jk_nwmain.lo ../../../build/jk2/apache2/jk_objCache.lo ../../../build/jk2/apache2/jk_pool_apr.lo ../../../build/jk2/apache2/jk_pool.lo ../../../build/jk2/apache2/jk_registry.lo ../../../build/jk2/apache2/jk_requtil.lo ../../../build/jk2/apache2/jk_shm.lo ../../../build/jk2/apache2/jk_signal.lo ../../../build/jk2/apache2/jk_uriEnv.lo ../../../build/jk2/apache2/jk_uriMap.lo ../../../build/jk2/apache2/jk_user.lo ../../../build/jk2/apache2/jk_vm_default.lo ../../../build/jk2/apache2/jk_worker_ajp13.lo ../../../build/jk2/apache2/jk_workerEnv.lo ../../../build/jk2/apache2/jk_worker_jni.lo ../../../build/jk2/apache2/jk_worker_lb.lo ../../../build/jk2/apache2/jk_worker_run.lo ../../../build/jk2/apache2/jk_worker_status.lo ranlib ../../../build/jk2/apache2/.libs/jkjni.a creating ../../../build/jk2/apache2/jkjni.la (cd ../../../build/jk2/apache2/.libs rm -f jkjni.la ln -s ../jkjni.la jkjni.la) /etc/httpd2/build/libtool --mode=install cp ../../../build/jk2/apache2/jkjni.la `pwd`/../../../build/jk2/apache2 cp ../../../build/jk2/apache2/.libs/jkjni.lai /home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.la cp ../../../build/jk2/apache2/.libs/jkjni.a /home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.a ranlib /home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.a chmod 644
cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache13 Makefile.in
jfclere 2002/11/28 07:06:36
Modified:jk/native2/server/apache13 Makefile.in
Log:
Arrange libtool logic.
Revision ChangesPath
1.6 +8 -3 jakarta-tomcat-connectors/jk/native2/server/apache13/Makefile.in
Index: Makefile.in
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache13/Makefile.in,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- Makefile.in 4 Jun 2002 10:33:45 - 1.5
+++ Makefile.in 28 Nov 2002 15:06:36 - 1.6
@@ -13,8 +13,9 @@
JK_DIR := ../..
BUILD_DIR = ${JK_DIR}/../build/jk2/apache13
+APACHE_LIBEXEC=${APACHE_HOME}/libexec
-#LIBTOOL=@LIBTOOL@
+LIBTOOL=@LIBTOOL@
# It doesn't hurt if we include all
INCLUDES= -I${JK_DIR}/include \
@@ -34,7 +35,8 @@
COMPILE = $(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(ALL_INCLUDES)
SH_COMPILE = $(LIBTOOL) --mode=compile $(COMPILE) $(JK_CFLAGS)
-MOD_LINK = $(LIBTOOL) --mode=link $(CC) -module -shared $(LT_LDFLAGS)
$(ALL_LDFLAGS) $(JK_LDFLAGS)
+MOD_LINK = $(LIBTOOL) --mode=link $(CC) -avoid-version -module -rpath
$(APACHE_LIBEXEC) $(LT_LDFLAGS) $(ALL_LDFLAGS) $(JK_LDFLAGS)
+MOD_INSTALL = $(LIBTOOL) --mode=install $(CP)
#
@@ -73,7 +75,10 @@
all: prepare ${BUILD_DIR}/mod_jk2.so
-${BUILD_DIR}/mod_jk2.so: ${COMMON_LO_FILES} ${A_LO_FILES}
+${BUILD_DIR}/mod_jk2.so: ${BUILD_DIR}/mod_jk2.la
+ $(MOD_INSTALL) cp $^ `pwd`/${BUILD_DIR}
+
+${BUILD_DIR}/mod_jk2.la: ${COMMON_LO_FILES} ${A_LO_FILES}
${MOD_LINK} -o $@ $^ @APR_LDFLAGS@
${COMMON_C_FILES} ${A_C_FILES}: ${H_FILES}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
remm2002/11/28 07:15:02
Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
Log:
- On the initial blocking call, I think the default socket timeout should be used.
- Make another call conditional on the disableUploadTimeout flag.
Revision ChangesPath
1.47 +5 -4
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
Index: Http11Processor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -r1.46 -r1.47
--- Http11Processor.java 26 Nov 2002 03:32:50 - 1.46
+++ Http11Processor.java 28 Nov 2002 15:15:02 - 1.47
@@ -396,10 +396,9 @@
int keepAliveLeft = maxKeepAliveRequests;
int soTimeout = socket.getSoTimeout();
+
boolean keptAlive = false;
-if( !disableUploadTimeout ) {
-socket.setSoTimeout(timeout);
-}
+
while (started !error keepAlive) {
try {
if( !disableUploadTimeout keptAlive soTimeout 0 ) {
@@ -407,7 +406,9 @@
}
inputBuffer.parseRequestLine();
keptAlive = true;
-socket.setSoTimeout(timeout);
+if (!disableUploadTimeout) {
+socket.setSoTimeout(timeout);
+}
inputBuffer.parseHeaders();
} catch (IOException e) {
error = true;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
remm2002/11/28 07:16:32
Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
Log:
- Small reorganization of the code so that the next accept is called sooner
when not using the connection cache.
Revision ChangesPath
1.8 +9 -12
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java
Index: PoolTcpEndpoint.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- PoolTcpEndpoint.java 28 Nov 2002 11:24:28 - 1.7
+++ PoolTcpEndpoint.java 28 Nov 2002 15:16:31 - 1.8
@@ -489,13 +489,7 @@
}
public void runIt(Object perThrData[]) {
- TcpConnection con=null;
- if( ! usePool ) {
- // extract the original.
- con=(TcpConnection) perThrData[0];
- perThrData = (Object []) perThrData[1];
- }
-
+
// Create per-thread cache
while(endpoint.isRunning()) {
Socket s = null;
@@ -521,14 +515,17 @@
continue;
}
+TcpConnection con = null;
try {
if( usePool ) {
con=(TcpConnection)connectionCache.get();
if( con == null )
con = new TcpConnection();
} else {
- if( con==null )
- continue;
+con = (TcpConnection) perThrData[0];
+perThrData = (Object []) perThrData[1];
+if ( con == null )
+continue;
}
con.setEndpoint(endpoint);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ANNOUNCEMENT] JK2-2.0.2 released
jean-frederic clere wrote: Henri Gomez wrote: Very weird. Send me the complete output of make. here it is : httpd2/lib -lcrypt -lapr-0 -lpcre -lpcreposix ../../../build/jk2/apache2/jk_jni_aprImpl.lo ../../../build/jk2/apache2/jk_channel_apr_socket.lo ../../../build/jk2/apache2/jk_channel.lo ../../../build/jk2/apache2/jk_channel_jni.lo ../../../build/jk2/apache2/jk_channel_socket.lo ../../../build/jk2/apache2/jk_channel_un.lo ../../../build/jk2/apache2/jk_config.lo ../../../build/jk2/apache2/jk_config_file.lo ../../../build/jk2/apache2/jk_endpoint.lo ../../../build/jk2/apache2/jk_env.lo ../../../build/jk2/apache2/jk_handler_logon.lo ../../../build/jk2/apache2/jk_handler_response.lo ../../../build/jk2/apache2/jk_logger_file.lo ../../../build/jk2/apache2/jk_logger_win32.lo ../../../build/jk2/apache2/jk_map.lo ../../../build/jk2/apache2/jk_md5.lo ../../../build/jk2/apache2/jk_msg_ajp.lo ../../../build/jk2/apache2/jk_mutex.lo ../../../build/jk2/apache2/jk_mutex_proc.lo ../../../build/jk2/apache2/jk_mutex_thread.lo ../../../build/jk2/apache2/jk_nwmain.lo ../../../build/jk2/apache2/jk_objCache.lo ../../../build/jk2/apache2/jk_pool_apr.lo ../../../build/jk2/apache2/jk_pool.lo ../../../build/jk2/apache2/jk_registry.lo ../../../build/jk2/apache2/jk_requtil.lo ../../../build/jk2/apache2/jk_shm.lo ../../../build/jk2/apache2/jk_signal.lo ../../../build/jk2/apache2/jk_uriEnv.lo ../../../build/jk2/apache2/jk_uriMap.lo ../../../build/jk2/apache2/jk_user.lo ../../../build/jk2/apache2/jk_vm_default.lo ../../../build/jk2/apache2/jk_worker_ajp13.lo ../../../build/jk2/apache2/jk_workerEnv.lo ../../../build/jk2/apache2/jk_worker_jni.lo ../../../build/jk2/apache2/jk_worker_lb.lo ../../../build/jk2/apache2/jk_worker_run.lo ../../../build/jk2/apache2/jk_worker_status.lo rm -fr ../../../build/jk2/apache2/.libs/jkjni.la ../../../build/jk2/apache2/.libs/jkjni.* ../../../build/jk2/apache2/.libs/jkjni.* *** Warning: This library needs some functionality provided by -lapr-0. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module jkjni. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. ar cru ../../../build/jk2/apache2/.libs/jkjni.a ../../../build/jk2/apache2/jk_jni_aprImpl.lo ../../../build/jk2/apache2/jk_channel_apr_socket.lo ../../../build/jk2/apache2/jk_channel.lo ../../../build/jk2/apache2/jk_channel_jni.lo ../../../build/jk2/apache2/jk_channel_socket.lo ../../../build/jk2/apache2/jk_channel_un.lo ../../../build/jk2/apache2/jk_config.lo ../../../build/jk2/apache2/jk_config_file.lo ../../../build/jk2/apache2/jk_endpoint.lo ../../../build/jk2/apache2/jk_env.lo ../../../build/jk2/apache2/jk_handler_logon.lo ../../../build/jk2/apache2/jk_handler_response.lo ../../../build/jk2/apache2/jk_logger_file.lo ../../../build/jk2/apache2/jk_logger_win32.lo ../../../build/jk2/apache2/jk_map.lo ../../../build/jk2/apache2/jk_md5.lo ../../../build/jk2/apache2/jk_msg_ajp.lo ../../../build/jk2/apache2/jk_mutex.lo ../../../build/jk2/apache2/jk_mutex_proc.lo ../../../build/jk2/apache2/jk_mutex_thread.lo ../../../build/jk2/apache2/jk_nwmain.lo ../../../build/jk2/apache2/jk_objCache.lo ../../../build/jk2/apache2/jk_pool_apr.lo ../../../build/jk2/apache2/jk_pool.lo ../../../build/jk2/apache2/jk_registry.lo ../../../build/jk2/apache2/jk_requtil.lo ../../../build/jk2/apache2/jk_shm.lo ../../../build/jk2/apache2/jk_signal.lo ../../../build/jk2/apache2/jk_uriEnv.lo ../../../build/jk2/apache2/jk_uriMap.lo ../../../build/jk2/apache2/jk_user.lo ../../../build/jk2/apache2/jk_vm_default.lo ../../../build/jk2/apache2/jk_worker_ajp13.lo ../../../build/jk2/apache2/jk_workerEnv.lo ../../../build/jk2/apache2/jk_worker_jni.lo ../../../build/jk2/apache2/jk_worker_lb.lo ../../../build/jk2/apache2/jk_worker_run.lo ../../../build/jk2/apache2/jk_worker_status.lo ranlib ../../../build/jk2/apache2/.libs/jkjni.a creating ../../../build/jk2/apache2/jkjni.la (cd ../../../build/jk2/apache2/.libs rm -f jkjni.la ln -s ../jkjni.la jkjni.la) /etc/httpd2/build/libtool --mode=install cp ../../../build/jk2/apache2/jkjni.la `pwd`/../../../build/jk2/apache2 cp ../../../build/jk2/apache2/.libs/jkjni.lai /home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.la cp ../../../build/jk2/apache2/.libs/jkjni.a /home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.a ranlib /home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.a chmod 644
Re: [ANNOUNCEMENT] JK2-2.0.2 released
BTW: How did you build the mod_jk2.so for Apache-2.0? mod_jk2.so didn't link against libapr, since apache2 allready provideit, but jkjni need it, that's why the build work for mod_jk2. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ANNOUNCEMENT] JK2-2.0.2 released
Henri Gomez wrote: BTW: How did you build the mod_jk2.so for Apache-2.0? mod_jk2.so didn't link against libapr, since apache2 allready provideit, but jkjni need it, that's why the build work for mod_jk2. Ok, forget that question! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk-2.0.42.so
Thanks, Henri ... You came from the sky Abraços, Pedro Igor - Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, November 28, 2002 10:59 AM Subject: Re: mod_jk-2.0.42.so Pedro Igor Craveiro e Silva wrote: Thakns. ... but just one more, i don´t find this mod, do you have a clue ?? It's next to the other one ! http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.1 /bin/linux/i386/mod_jk-1.3-eapi.so -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk-2.0.42.so
Pedro Igor Craveiro e Silva wrote: Thanks, Henri ... You came from the sky heuu, no from Lyon, France ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk-2.0.42.so
Do you know what for is this libc.so.6 ? When i run the httpd, he return that this shared lib could not be found. Pedro Igor - Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, November 28, 2002 10:59 AM Subject: Re: mod_jk-2.0.42.so Pedro Igor Craveiro e Silva wrote: Thakns. ... but just one more, i don´t find this mod, do you have a clue ?? It's next to the other one ! http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.1 /bin/linux/i386/mod_jk-1.3-eapi.so -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk-2.0.42.so
On 28/11/02 17:25 Pedro Igor Craveiro e Silva [EMAIL PROTECTED] wrote: Do you know what for is this libc.so.6 ? Main C library for Linux, the one that contains also printf... When i run the httpd, he return that this shared lib could not be found. Then you're in troubles. Update your Linux install to something more recent (including the new LIBC) or recompile the whole kit-n-kaboodle... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] [Proposal] Adding an authorization interface
Costin Manolache wrote: Jeanfrancois Arcand wrote: Sorry, I missed the first part of the discussion. Why would someone use this instead of web.xml ? Because you can start using the java.security.Provider.checkPermission for granting/denying resources. Not sure this would be the most efficient solution - the mapper is ( or will be ) optimized on the way it is used in tomcat. But I see your point - and I think it would be nice to use similar concepts or API. If by authorization you mean deciding in an URL can be accessed by a user - I think the mapper ( or a similar valve ) is the best solution, using the informations in web.xml. Exactly. The similar valve :-) is the AuthenticatorBase, who delegate part of the authorization decision to the RealmBase, as well as part of authentication. I'm +1 to delegate the authentication to the RealBase, but -1 to delegate the authorization (this is how it is implemented right now). What I recommend is to remove the authorization code from the RealmBase and move it to the AutorizerBase. It's just refactoring one class into 2. Then we will be able to use JAAS (or 115, LDAP, NFS, etc.) in a cleaner way. Using JAAS as an interface will have to happen somewhere in AuthenticatorBase RealmBase. Since in JAAS there is a clear separation between authentication/autorization, why not have the same separation in Tomcat by having Realm Authorizer (instead of only Realm). I agree that authenticate and authorize are 2 different hooks and need to be separated. Let me think about it - and maybe get some other opinions. I would very much preffer a consistent mechanism for all the hooks in tomcat. In 3.3 there is one interface ( BaseInterceptor ) where all the possible hooks are defined ( with a number of problems we already know regarding ordering, but that's a different issue ). In 4.x Valves are used as the main extension mechanism, but also Listeners, Realms, Connectors and few other interfaces - and I would very much prefer a solution that is more consistent and simpler. For example - move it at Coyote level and use an ActionCode for authorization. Things are not very well defined for chaining the coyote actions, but it can be done easily. All hooks could be defined as coyote Actions - instead of having a specific Authorizer interface you'll have an authorizer action. Does it sound acceptable ? I would mention that this is how authorization is implemented in apache ( and most web servers ), and it would probably make it easier to integrate. Well, there is just a style difference between having a generic hook and having one specific interface like Authorizer, but for a lot of people understanding the hook mechanism and the particular hooks is easier than dealing with dozens of slightly different interfaces. I'll only be talking about HTTP authentication and the interaction with the realms for now. The main problem is that some authentication schemes need the realm to function (digest, for example). So I don't see how we can put that layer of processing in Coyote, since we need access to the realm to perform it. However, the code in the current authenticators will enventually be rewritten Coyote-style (and using tomcat-util objects) so that it actually performs well. I think a refactoring of the realms is needed in order to support any auth scheme (most realms don't work with digest). To be able to do digest and basic using the same realm, one need either: - the clear text password of the user (not good for security) - the limited digest (I think that's how it's called in the HTTP Auth RFC; look there for more details) We should probably standardize on storing the limited digest defined in the RFC in the realms instead of the clear password or some kind of unusable digest of the password. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] [Proposal] Adding an authorization interface
Remy Maucherat wrote: I'll only be talking about HTTP authentication and the interaction with the realms for now. The main problem is that some authentication schemes need the realm to function (digest, for example). So I don't see how we can put that layer of processing in Coyote, since we need access to the realm to perform it. However, the code in the current authenticators will enventually be rewritten Coyote-style (and using tomcat-util objects) so that it actually performs well. That's orthogonal and not the subject of this discussion ( the proposal is about authorization, not authentication ). Also the issue of using coyote hooks ( Action ) or a custom interface is orthogonal on what information is needed, in both cases the implementation of the authentication hook ( or interface ) will have access to the same information ( Request, user info, etc ). I think a refactoring of the realms is needed in order to support any auth scheme (most realms don't work with digest). To be able to do +1. I would add to the wish list better support for web server integration. It would be nice ( at least for jni mode ) to be able to have the native server call the hook to auth static resources - but the real important thing is allow the native server do it ( and the countless auth modules ). We should probably standardize on storing the limited digest defined in the RFC in the realms instead of the clear password or some kind of unusable digest of the password. I like the move to split the storage of the info about user from Realm, as well as the split of authorization/authentication. I don't like the current abstraction for user info ( and the fact that all users need to be in memory ), and I would preffer use of a consistent hook mechanism ( coyote Action ) instead of special interfaces. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk-2.0.42.so
I´m not using Linux, but FreeBSD. Pedro Igor - Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, November 28, 2002 1:42 PM Subject: Re: mod_jk-2.0.42.so Pedro Igor Craveiro e Silva wrote: Do you know what for is this libc.so.6 ? When i run the httpd, he return that this shared lib could not be found. Which release of Linux are you using ? -- 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.16] Benchmarks
Peter Lin wrote: yeah, I can do that on a simple set this weekend and on a large webapp next week :) Thanks Peter. Since the 4.1 API can't be expanded, and I'm now pretty much done for Coyote and HTTP/1.1 optimizations, 4.1.16 is more or less the best that can be achieved with 4.1.x. So that's why doing benchmarks on that release is interesting. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] [Proposal] Adding an authorization interface
Costin Manolache wrote: Remy Maucherat wrote: I'll only be talking about HTTP authentication and the interaction with the realms for now. The main problem is that some authentication schemes need the realm to function (digest, for example). So I don't see how we can put that layer of processing in Coyote, since we need access to the realm to perform it. However, the code in the current authenticators will enventually be rewritten Coyote-style (and using tomcat-util objects) so that it actually performs well. That's orthogonal and not the subject of this discussion ( the proposal is about authorization, not authentication ). Yes, I know ;-) It's not too often that people talk about refactoring that part of Tomcat, so I wanted to mention that issue. Also the issue of using coyote hooks ( Action ) or a custom interface is orthogonal on what information is needed, in both cases the implementation of the authentication hook ( or interface ) will have access to the same information ( Request, user info, etc ). Yes, you can indeed pass the necessary information as a parameter. I think a refactoring of the realms is needed in order to support any auth scheme (most realms don't work with digest). To be able to do +1. I would add to the wish list better support for web server integration. It would be nice ( at least for jni mode ) to be able to have the native server call the hook to auth static resources - but the real important thing is allow the native server do it ( and the countless auth modules ). We should probably standardize on storing the limited digest defined in the RFC in the realms instead of the clear password or some kind of unusable digest of the password. I like the move to split the storage of the info about user from Realm, as well as the split of authorization/authentication. I don't like the current abstraction for user info ( and the fact that all users need to be in memory ), and I would preffer use of a consistent hook mechanism ( coyote Action ) instead of special interfaces. I don't care that much about the hook mechanism (the current one works ok), but the user storage is certainly broken, and this part of Tomcat could generally be more elegant (but maybe something implementing FORM cannot be made to be elegant :-P ). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk-2.0.42.so
Pedro Igor Craveiro e Silva wrote: I´m not using Linux, but FreeBSD. Hum, that's why !!! BTW, the is no Apache 1.3 binary for FreeBSD, I only built one for Apache 2.0 ;( -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk-2.0.42.so
Ok. But, with that first module(mod_jk2.(etc)) the i was using i can put the apache e tomcat together? Pedro Igor - Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, November 28, 2002 2:31 PM Subject: Re: mod_jk-2.0.42.so Pedro Igor Craveiro e Silva wrote: I´m not using Linux, but FreeBSD. Hum, that's why !!! BTW, the is no Apache 1.3 binary for FreeBSD, I only built one for Apache 2.0 ;( -- 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]
[PATCH] TagPoolSize for 4.1.16, outsourcing TemplateText to static String/char arrays variables
Here is a patch. - to port back the TagPoolSize Option from 5.0. - adding to choice to use static String/char arrays for static templatetext. - try/catch/finally blocks for calling release/reuse even if a exception occurs methods on taghandlers. open things: - try/finally working with Tags that implement TryCatchFinally - docs at web.xml - cu Torsten Fohrer StaticTagPool.patch Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] [Proposal] Adding an authorization interface
Costin Manolache wrote: Jeanfrancois Arcand wrote: Why would someone use this instead of web.xml ? Because you can start using the java.security.Provider.checkPermission for granting/denying resources. Not sure this would be the most efficient solution - the mapper is ( or will be ) optimized on the way it is used in tomcat. But I see your point - and I think it would be nice to use similar concepts or API. If by authorization you mean deciding in an URL can be accessed by a user - I think the mapper ( or a similar valve ) is the best solution, using the informations in web.xml. Exactly. The similar valve :-) is the AuthenticatorBase, who delegate part of the authorization decision to the RealmBase, as well as part of authentication. I'm +1 to delegate the authentication to the RealBase, but -1 to delegate the authorization (this is how it is implemented right now). What I recommend is to remove the authorization code from the RealmBase and move it to the AutorizerBase. It's just refactoring one class into 2. Then we will be able to use JAAS (or 115, LDAP, NFS, etc.) in a cleaner way. Using JAAS as an interface will have to happen somewhere in AuthenticatorBase RealmBase. Since in JAAS there is a clear separation between authentication/autorization, why not have the same separation in Tomcat by having Realm Authorizer (instead of only Realm). I agree that authenticate and authorize are 2 different hooks and need to be separated. Let me think about it - and maybe get some other opinions. I would very much preffer a consistent mechanism for all the hooks in tomcat. In 3.3 there is one interface ( BaseInterceptor ) where all the possible hooks are defined ( with a number of problems we already know regarding ordering, but that's a different issue ). In 4.x Valves are used as the main extension mechanism, but also Listeners, Realms, Connectors and few other interfaces - and I would very much prefer a solution that is more consistent and simpler. Just downloaded 3.3 code base. I will take a look at the way it work. I not familiar with 3.3 code base. For example - move it at Coyote level and use an ActionCode for authorization. Things are not very well defined for chaining the coyote actions, but it can be done easily. All hooks could be defined as coyote Actions - instead of having a specific Authorizer interface you'll have an authorizer action. Does it sound acceptable ? I would mention that this is how authorization is implemented in apache ( and most web servers ), and it would probably make it easier to integrate. Let me learn in more detail the coyote stuff and think about it. I was trying to align the change with the current Valve/Realm implementation, but exploring other avenues for sure will help defining a better design. I will come back soon on the subject. Well, there is just a style difference between having a generic hook and having one specific interface like Authorizer, but for a lot of people understanding the hook mechanism and the particular hooks is easier than dealing with dozens of slightly different interfaces. I agree. If It possible, I will come up with an ActionCode. If not, then we should use the Authorizer idea. Thanks, -- Jeanfrancois Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14943] New: - // style scriptlet comment with % on same line comments out the next out.write(...)
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=14943. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14943 // style scriptlet comment with % on same line comments out the next out.write(...) Summary: // style scriptlet comment with % on same line comments out the next out.write(...) Product: Tomcat 4 Version: 4.1.12 Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] A // style sciptlet comment with % on same line comments out the next out.write (...) statement. Consider the following jsp code. == % // This is a comment % This should be displayed on the screen. br The end. == This is the java output. == // This is a comment out.write(\r\nThis should be displayed on the screen. ); out.write(br\r\nThe end.\r\n); == By placing the %, it wipes out the first out.write. The workaround is to place the ending % on a new line. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14944] New: - conflict with NAV2003
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=14944. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14944 conflict with NAV2003 Summary: conflict with NAV2003 Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows XP Status: NEW Severity: Blocker Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] when tomcat/catalina is set to boot with the login of my startup account, it shuts down the NAV autoprotect with characteristics of a virus. i can't run NAV if tomcat is in startup (not a system service for other problems), but after system boots completely, i can run tomcat with no problems. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk-2.0.42.so
On 28/11/02 7:37 pm, in article 000701c2970d$2d408f90$[EMAIL PROTECTED], Pedro Igor Craveiro e Silva [EMAIL PROTECTED] wrote: Ok. But, with that first module(mod_jk2.(etc)) the i was using i can put the apache e tomcat together? FreeBSD contains a Linux emulator, but AFAICR, it ships currently with GLIBC-5 ... You'd better off recompiling the module (Apache part) native for FreeBSD and the JNI lib for Linux GLIBC-5... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Servlet Filter in Tomcat 3.3.1
Hi all, can filter be applied in Tomcat 3.3.1. did anyone try filters in tomcat3.3.1 if so please tell me the sequnce... thanks in advance Regards Laxmikanth M S Off* : 91-80-6610330 extn 1256 Res* : 91-80-5267150 http://www.sonata-software.com Coming together is the beginning, staying together is progress and working together is Success What lies behind us and what lies before us are tiny matters compared to what lies within us - Emerson * Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. * -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
