[PATCH] mod_jk2 compile on WIN32
Hi, all
Here are the two patches that enables WIN32 compilation of mod_jk2.
Tested on 2.0.37-dev.
I think that module should be named mod_jk2(right?), and since use the
APR by default.
MT.
Index: jk_env.c
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native2/common/jk_env.c,v
retrieving revision 1.28
diff -u -r1.28 jk_env.c
--- jk_env.c24 May 2002 04:26:00 - 1.28
+++ jk_env.c27 May 2002 07:35:42 -
@@ -72,7 +72,7 @@
/* Env management */
-static void JK_METHOD *jk2_env_getAprPool( jk_env_t *env ) {
+static void * JK_METHOD jk2_env_getAprPool( jk_env_t *env ) {
#ifdef HAS_APR
/* We don't want to have to recreate the scoreboard after
* restarts, so we'll create a global pool and never clean it.
Index: mod_jk.dsp
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_
jk.dsp,v
retrieving revision 1.2
diff -u -r1.2 mod_jk.dsp
--- mod_jk.dsp 16 May 2002 20:54:57 - 1.2
+++ mod_jk.dsp 27 May 2002 07:36:36 -
@@ -43,7 +43,7 @@
# PROP Ignore_Export_Lib 0
# PROP Target_Dir
# ADD BASE CPP /nologo /MD /W3 /O2 /D WIN32 /D NDEBUG /D _WINDOWS
/FD /c
-# ADD CPP /nologo /MD /W3 /O2 /I ..\common /I $(JAVA_HOME)\include
/I $(JAVA_HOME)\include\win32 /I $(APACHE2_HOME)\include /I
$(APACHE2_HOME)\srclib\apr\include /I
$(APACHE2_HOME)\srclib\apr-util\include /D NDEBUG /D WIN32 /D
_WINDOWS /FdRelease\mod_jk /FD /c
+# ADD CPP /nologo /MD /W3 /O2 /D HAS_APR /I ..\..\common /I
..\..\include /I $(JAVA_HOME)\include /I
$(JAVA_HOME)\include\win32 /I $(APACHE2_HOME)\include /I
$(APACHE2_HOME)\srclib\apr\include /I
$(APACHE2_HOME)\srclib\apr-util\include /D NDEBUG /D WIN32 /D
_WINDOWS /FdRelease\mod_jk2 /FD /c
# ADD BASE MTL /nologo /D NDEBUG /mktyplib203 /win32
# ADD MTL /nologo /D NDEBUG /mktyplib203 /win32
# ADD BASE RSC /l 0x409 /d NDEBUG
@@ -53,7 +53,7 @@
# ADD BSC32 /nologo
LINK32=link.exe
# ADD BASE LINK32 kernel32.lib user32.lib advapi32.lib /nologo /dll
/machine:I386
-# ADD LINK32 libhttpd.lib libapr.lib libaprutil.lib kernel32.lib
user32.lib advapi32.lib wsock32.lib /nologo /dll /machine:I386
/libpath:$(APACHE2_HOME)\Release
/libpath:$(APACHE2_HOME)\srclib\apr\Release
/libpath:$(APACHE2_HOME)\srclib\apr-util\Release
/libpath:$(APACHE2_HOME)\lib
+# ADD LINK32 libhttpd.lib libapr.lib libaprutil.lib kernel32.lib
user32.lib advapi32.lib wsock32.lib /nologo /dll /machine:I386
/out:Release/mod_jk2.so /libpath:$(APACHE2_HOME)\Release
/libpath:$(APACHE2_HOME)\srclib\apr\Release
/libpath:$(APACHE2_HOME)\srclib\apr-util\Release
/libpath:$(APACHE2_HOME)\lib
!ELSEIF $(CFG) == apache - Win32 Debug
@@ -69,7 +69,7 @@
# PROP Ignore_Export_Lib 0
# PROP Target_Dir
# ADD BASE CPP /nologo /MDd /W3 /GX /Zi /Od /D WIN32 /D _DEBUG /D
_WINDOWS /FD /c
-# ADD CPP /nologo /MDd /W3 /GX /Zi /Od /I ..\..\include /I
..\include /I . /I $(JAVA_HOME)\include /I
$(JAVA_HOME)\include\win32 /I $(APACHE2_HOME)\include /D _DEBUG /D
WIN32 /D _WINDOWS /D HAS_APR /FdDebug\mod_jk /FD /c
+# ADD CPP /nologo /MDd /W3 /GX /Zi /Od /D HAS_APR /I ..\..\include
/I ..\include /I . /I $(JAVA_HOME)\include /I
$(JAVA_HOME)\include\win32 /I $(APACHE2_HOME)\include /D _DEBUG /D
WIN32 /D _WINDOWS /D HAS_APR /FdDebug\mod_jk2 /FD /c
# ADD BASE MTL /nologo /D _DEBUG /mktyplib203 /win32
# ADD MTL /nologo /D _DEBUG /mktyplib203 /win32
# ADD BASE RSC /l 0x409 /d _DEBUG
@@ -79,7 +79,7 @@
# ADD BSC32 /nologo
LINK32=link.exe
# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib
odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /pdbtype:sept
-# ADD LINK32 libhttpd.lib libapr.lib libaprutil.lib kernel32.lib
user32.lib advapi32.lib wsock32.lib /nologo /dll /debug /machine:I386
/out:Debug/mod_jk2.dll /libpath:$(APACHE2_HOME)/Debug
/libpath:$(APACHE2_HOME)\srclib\apr\Debug
/libpath:$(APACHE2_HOME)\srclib\apr-util\Debug
/libpath:$(APACHE2_HOME)\lib
+# ADD LINK32 libhttpd.lib libapr.lib libaprutil.lib kernel32.lib
user32.lib advapi32.lib wsock32.lib /nologo /dll /debug /machine:I386
/out:Debug/mod_jk2.so /libpath:$(APACHE2_HOME)/Debug
/libpath:$(APACHE2_HOME)\srclib\apr\Debug
/libpath:$(APACHE2_HOME)\srclib\apr-util\Debug
/libpath:$(APACHE2_HOME)\lib
!ENDIF
@@ -104,6 +104,10 @@
# End Source File
# Begin Source File
+SOURCE=..\..\common\jk_channel_un.c
+# End Source File
+# Begin Source File
+
SOURCE=..\..\common\jk_config.c
# End Source File
# Begin Source File
@@ -197,10 +201,6 @@
# Begin Source File
SOURCE=..\..\common\jk_worker_ajp13.c
-# End Source File
-# Begin Source File
-
-SOURCE=..\..\common\jk_worker_ctl.c
# End Source File
# Begin Source File
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
APR patch? Was: [VOTE] New Committer Dan Sandberg
Pier Fumagalli wrote: Dan Sandberg [EMAIL PROTECTED] wrote: Granting that I'm not as experienced with open-source collaboration as the rest of you are, Don't worry, I'm here since 1997 and I'm probably the most clueless of all freaks... :) my intuition is that the easier it is for people to make changes to the code-base ( assuming their contributions are reviewed ) the faster the code-base will improve and bugs will be eliminated. Again, this is contigent on the belief that contributions will be reviewed by somebody for security, bugs, and code quality. This is absolutely true. Fresh blood is what we _need_. I'm not arguing with it, and I'm not arguing with the fact that it's just _easier_ to have CVS access... One example from somewhere else, I have a small patch for APR, the Apache Portable Runtime, I just need to change a ... (quote) in a [...] (square bracket) in an M4 macro because it might break stuff somewhere (it seems that all M4 versions actually interpret it in the same way, but there's a slight difference). This is on 3 lines of their configure.in, and I submitted it 3 months ago? _noone_ committed it yet, once every week I resubmit it, but it's such a tiny thing that noone actually cares to commit (I would do exactly the same). If I had CVS access I would do it myself (I can actually grant me cvs access, commit that patch and be gone, and I'm sure noone would complain), but... Real story? Send me the patch, I will make a try ;-) As for the question that Pier asked: How much responsibility am I willing to take on? I am willing to address bugs, and review contributions to the SSI code. I would usually not vote on committers unless I know that they should be + or -, which will be rare. Similarly, I would vote on release plans, the future of the project, etc., if and only if I feel I had something to add in those areas, which will probably be rare. Great, that's what we expect from committers, I'm going to strike my -1 and make it a +1, but please don't let me down and disappear in 2 months! :) :) If you want to know the real price of becoming a commiter - it's loosing all control over the code you write, having to play flame wars and grow a thick skin. And you may spend many weekends doing work that is just thrown away. I'm thick-headed and thick-skinned, so this is not a problem. I'll skip on the flame wars though. :) Too bad, I would like to have a flame buddy from time to time... Are you interested? I don't want to sound bad, but hey everything comes at a price :) :) :) I don't view committer status as a trophy. I just want to fix things that are broken. Having commit access makes this easier for me and for everyone else. I do view committer status as a trophy, probably because I had to put sweat and blood in getting it years ago, and still, I'm struggling to get one on APR, or on HTTPD, I help out when I can, I play with the big boys, one day someone will just say I'd like Pier to be a committer, and that will be one of the best days in my life... But don't worry that on that day there won't be anyone who could say who's this guy?... If you want my advice - create a sourceforge account, do all the work on SSI there, and have fun. ( and maybe give access to other tomcat commiters who are interested to work on SSI ). Not sure how this helps. If I understand the suggestion correctly, this is equivalent to forking the SSI code, which definitely won't help the development process. No, it won't and frankly it's something I wouldn't have wanted to hear from a committer, a seasoned one, and a PMC member. I am trying, struggling to build something, like most of us I'm not paid for what I do here (I used to be, and I can tell you, now that I'm out, I wouldn't go back). Just saying get off to SourceForge and build your thing over there doesn't go around in my book... I just read Pier's proposal, and I agree with him. Cheers, thanks, I'm going to waive my -1 so that you can vote +1 on my proposal, then :) :) :) Sorry to have instigated all this, but I suppose it's something that would have had to be dealt with sooner or later... You're right, it's just a casus belli as Romans might say. Now that the discussion is undergoing (I hope), I would like to welcome you to the big PHAT Jakarta Community, and please, as a (rejected before and then welcomed) committer, keep your thoughts coming... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9375] - JSP class loading failure with derived tags
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=9375. 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=9375 JSP class loading failure with derived tags --- Additional Comments From [EMAIL PROTECTED] 2002-05-27 08:01 --- Tomcat uses the JDK 1.3 from IBM on my machine. Does its compiler have the same differences between modern and classic? Or do i have to use Suns JDK (which with my applications is much slower due to the garbage collector). Is there a possibility to use IBMs JDK for execution, but Suns javac for jaspers compiling and how do i set this up? Thank you, Jens Stutte -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9434] New: - Response Filters do not work with jsp:forward
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=9434. 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=9434 Response Filters do not work with jsp:forward Summary: Response Filters do not work with jsp:forward Product: Tomcat 4 Version: 4.0.4 Beta 3 Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Any jsp:forward /-tag resets the response-object without reconstruction assigned filters to neither the hidden destination address nor the source URL. Result: You cannot use jsp:forward with any output filter that has to process every page. Most simple test scenario: Activate the compression servlet from the /examples context: -!-- filter-mapping filter-nameCompression Filter/filter-name - url-pattern/CompressionTest/url-pattern + url-pattern/*/url-pattern /filter-mapping --- Create a page test2.jsp: h1Test-Page 2/h1 This is just a short page to demonstrate compression. It has to be sufficiently long to trigger compression. and a page test1.jsp: jsp:forward page=test2.jsp / Calling test2.jsp will result in a filtered output, calling test1.jsp will not. Tested with 4.04 beta 3 and 4.1.2 alpha. Cheers, Georg -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
import tyrex.jdbc.ServerDataSource;
Hello All, Can anyone help me please, I am very new to Tomcat source code and I've got a problem: Tomcat requires Tyrex-0.9.7 for build but as it was allready caught it is not available for download any more. There is only 1.0 bundle available whcih even has no tyrex.jdbc.* package inside. So, it is not possible to compile tomcat without source modification. I suppose you guys are going to use new package very soon, but can anyone please send me tyrex-0.9.7.jar Best regards, Denis -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: import tyrex.jdbc.ServerDataSource;
Denis Markov wrote: Hello All, Can anyone help me please, I am very new to Tomcat source code and I've got a problem: Tomcat requires Tyrex-0.9.7 for build but as it was allready caught it is not available for download any more. There is only 1.0 bundle available whcih even has no tyrex.jdbc.* package inside. So, it is not possible to compile tomcat without source modification. I suppose you guys are going to use new package very soon, but can anyone please send me tyrex-0.9.7.jar Use the tyrex-1.0. I will commit the changes I prepared for that last week. Best regards, Denis -- 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-4.0 BUILDING.txt build.properties.sample
jfclere 02/05/27 03:01:12
Modified:.BUILDING.txt build.properties.sample
Log:
Update tyrex to 1.0.
Revision ChangesPath
1.30 +2 -2 jakarta-tomcat-4.0/BUILDING.txt
Index: BUILDING.txt
===
RCS file: /home/cvs/jakarta-tomcat-4.0/BUILDING.txt,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- BUILDING.txt 15 Apr 2002 09:42:03 - 1.29
+++ BUILDING.txt 27 May 2002 10:01:12 - 1.30
@@ -1,4 +1,4 @@
-$Id: BUILDING.txt,v 1.29 2002/04/15 09:42:03 remm Exp $
+$Id: BUILDING.txt,v 1.30 2002/05/27 10:01:12 jfclere Exp $
Building The Tomcat 4.0 Servlet/JSP Container
@@ -355,7 +355,7 @@
NOTE: This step is only required if you wish to build the Tyrex connection
pool implementation for JNDI-accessed data sources.
-* Download the Tyrex JAR or release (version 0.9.7) from:
+* Download the Tyrex JAR or release (version 1.0) from:
http://tyrex.exolab.org/download.html
1.40 +5 -5 jakarta-tomcat-4.0/build.properties.sample
Index: build.properties.sample
===
RCS file: /home/cvs/jakarta-tomcat-4.0/build.properties.sample,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- build.properties.sample 8 May 2002 21:00:20 - 1.39
+++ build.properties.sample 27 May 2002 10:01:12 - 1.40
@@ -6,7 +6,7 @@
# modules that Tomcat depends on. Copy this file to build.properties
# in the top-level source directory, and customize it as needed.
#
-# $Id: build.properties.sample,v 1.39 2002/05/08 21:00:20 jfclere Exp $
+# $Id: build.properties.sample,v 1.40 2002/05/27 10:01:12 jfclere Exp $
# -
@@ -219,10 +219,10 @@
struts.loc=http://jakarta.apache.org/builds/jakarta-struts/release/v1.0.2/jakarta-struts-1.0.2.tar.gz
-# - Tyrex Data Source, version 0.9.7 -
-tyrex.home=${base.path}/tyrex-0.9.7.0
+# - Tyrex Data Source, version 1.0 -
+tyrex.home=${base.path}/tyrex-1.0
tyrex.lib=${tyrex.home}
-tyrex.jar=${tyrex.lib}/tyrex-0.9.7.0.jar
-tyrex.loc=ftp://ftp.exolab.org/pub/tyrex/tyrex-0.9.7.0/tyrex-0.9.7.0.jar
+tyrex.jar=${tyrex.lib}/tyrex-1.0.jar
+tyrex.loc=ftp://ftp.exolab.org/pub/tyrex/tyrex-1.0/tyrex-1.0.jar
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8438] - Unable to start Apache service when using mod_jk
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=8438. 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=8438 Unable to start Apache service when using mod_jk --- Additional Comments From [EMAIL PROTECTED] 2002-05-27 10:41 --- Look at http://www.acg-gmbh.de/mod_jk for this topic! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9439] New: - mod_jk on solaris not working with apache 2.0.35
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=9439.
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=9439
mod_jk on solaris not working with apache 2.0.35
Summary: mod_jk on solaris not working with apache 2.0.35
Product: Tomcat 4
Version: 4.0.3 Final
Platform: Sun
OS/Version: Solaris
Status: NEW
Severity: Critical
Priority: Other
Component: Connector:Other
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
In trying to get mod_jk to work on Solaris 8 for apache 2.0.35, i found a
problem in the startup, which is that the function init_jk was getting called
multiple times when it should not have been. This led to the number of workers
being doubled and then it was not working.
The fix is simple: add the same check that appears in the function
jk_post_config to the child_init function, so that the code reads as follows:
if(!conf-was_initialized) {
conf-was_initialized = JK_TRUE;
init_jk( pconf, conf, s );
}
instead of just calling the init_jk without that check.
I also found that apxs was not working as expected, perhaps due to the fact
that it was missing -G in the gcc command, but I am not sure
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9440] New: - build-unix.sh does not build on solaris 8 for apache2.0.35
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=9440. 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=9440 build-unix.sh does not build on solaris 8 for apache2.0.35 Summary: build-unix.sh does not build on solaris 8 for apache2.0.35 Product: Tomcat 4 Version: 4.0.3 Final Platform: Sun OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Connector:Other AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I tried to build mod_jk from the source jakarta-tomcat-connectors-4.0.2-01- src.tar for solaris 8 but the compile did not work. It seemed to try to be linking with all the apache libraries even though it was building a shared library. It also could not find the other libraries, like socket. I am not sure if the problem is with the file or with apxs, which I was using from apache2.0.35. The simple workaround is not to use apxs and build with regular makefile. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
j-t-c/ build.xml: Incorrect Dir Used
In j-t-c/ build.xml the jar element contains a fileset dir subelement/attribute that points to jk/build/WEB-INF/classes however the dir path that's being created in j-t-c/jk/ build.xml is jk/build/classes. Thank You, Anthony -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
getSigners and WebappClassLoader
Hi Remy, just a short follow up to check if you have received my previous change suggestion for WebappClassLoader. Everything in order? Regards, Michael Eriksson -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2 buildconf.sh
jfclere 02/05/27 06:28:03 Modified:jk/native2 buildconf.sh Log: Copy instead of symlink the libtool files. Revision ChangesPath 1.6 +2 -2 jakarta-tomcat-connectors/jk/native2/buildconf.sh Index: buildconf.sh === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/buildconf.sh,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- buildconf.sh 24 May 2002 07:07:23 - 1.5 +++ buildconf.sh 27 May 2002 13:28:03 - 1.6 @@ -1,7 +1,7 @@ #!/bin/sh -echo libtoolize --force --automake -libtoolize --force --automake +echo libtoolize --force --automake --copy +libtoolize --force --automake --copy echo automake --copy --add-missing automake --copy --add-missing echo aclocal -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector RequestBase.java
glenn 02/05/27 06:34:34
Modified:catalina/src/share/org/apache/catalina/connector
RequestBase.java
Log:
Only log if their is text to log
Revision ChangesPath
1.20 +5 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/RequestBase.java
Index: RequestBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/RequestBase.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- RequestBase.java 23 May 2002 17:22:37 - 1.19
+++ RequestBase.java 27 May 2002 13:34:34 - 1.20
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/RequestBase.java,v
1.19 2002/05/23 17:22:37 glenn Exp $
- * $Revision: 1.19 $
- * $Date: 2002/05/23 17:22:37 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/RequestBase.java,v
1.20 2002/05/27 13:34:34 glenn Exp $
+ * $Revision: 1.20 $
+ * $Date: 2002/05/27 13:34:34 $
*
*
*
@@ -100,7 +100,7 @@
* the connector-specific methods need to be implemented.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.19 $ $Date: 2002/05/23 17:22:37 $
+ * @version $Revision: 1.20 $ $Date: 2002/05/27 13:34:34 $
* @deprecated
*/
@@ -560,7 +560,7 @@
public void recycle() {
String log = SystemLogHandler.stopCapture();
-if (log != null) {
+if (log != null log.length() 0) {
context.getServletContext().log(log);
}
attributes.clear();
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
j-t-c/jk/ build.properties.sample: Incorrect Syntax???
In several places within j-t-c/jk/ build.properties.sample there are
assignment values using parentheses instead of brackets.
For example:
apr.home=$(apache2.home)
instead of:
apr.home=${apache2.home)
Thank You,
Anthony
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: j-t-c/jk/ build.properties.sample: Incorrect Syntax???
On Monday 27 May 2002 09:48 am, Anthony W. Marino wrote:
In several places within j-t-c/jk/ build.properties.sample there are
assignment values using parentheses instead of brackets.
For example:
apr.home=$(apache2.home)
instead of:
apr.home=${apache2.home)
Ooops:
apr.home=${apache2.home}
Anthony
Thank You,
Anthony
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/apr AprInputStream.java AprOutputStream.java
glenn 02/05/27 07:42:47
Modified:jk/java/org/apache/jk/apr AprInputStream.java
AprOutputStream.java
Log:
Method signatures for APR no longer matched which broke the build.
Updated the method signatures to match Costin's latest changes.
Revision ChangesPath
1.2 +1 -1
jakarta-tomcat-connectors/jk/java/org/apache/jk/apr/AprInputStream.java
Index: AprInputStream.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/apr/AprInputStream.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- AprInputStream.java 12 Jan 2002 04:00:15 - 1.1
+++ AprInputStream.java 27 May 2002 14:42:47 - 1.2
@@ -96,7 +96,7 @@
public int read() throws IOException {
byte buf [] = new byte[1];
-if ( apr.unRead( pool, fd, buf, 0, 1) 0)
+if ( apr.unRead( fd, buf, 0, 1) 0)
throw new IOException();
return 0xff buf[0];
}
1.2 +2 -2
jakarta-tomcat-connectors/jk/java/org/apache/jk/apr/AprOutputStream.java
Index: AprOutputStream.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/apr/AprOutputStream.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- AprOutputStream.java 12 Jan 2002 04:00:15 - 1.1
+++ AprOutputStream.java 27 May 2002 14:42:47 - 1.2
@@ -100,12 +100,12 @@
// based on type select the native write method
// Or separate classes for each type - but we expect UNIX
// sockets to be integrated in apr
-if ( apr.unWrite( pool, fd, buf, 0, 1 ) 0)
+if ( apr.unWrite( fd, buf, 0, 1 ) 0)
throw new IOException();
}
public void write(byte b[], int off, int len) throws IOException {
-if ( apr.unWrite( pool, fd, b, off, len ) 0)
+if ( apr.unWrite( fd, b, off, len ) 0)
throw new IOException();
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
large requests crash mod_jk on HP-UX 11.0
I am really a tomcat user, but I have ended up trolling through the mod_jk code looking for this bug, so I thought this was the appropriate place to post my discoveries; Background: Our Unix team have built Apache from the source for HP-UX 11.0 with the HP cc compiler, not gcc. cpp and ccom versions are A.11.01.00, ld version is B.11.25 mod_jk has been built with the same compiler using apxs and the build-hpux-cc.sh script. Apache is version 1.3.22. The mod_jk source comes from the file jakarta-tomcat-connectors-4.0.2-01-src.zip from the Jakarta site. The problem: Mostly this build works except: certain URL's on our site fail with an internal server error message to the browser. The request doesn't show up in Apache's access log. The following shows up in Apache's error log: [Mon May 27 14:07:01 2002] [notice] child pid 13574 exit signal Segmentation fault (11) [Mon May 27 14:07:01 2002] [notice] child pid 12572 exit signal Segmentation fault (11) always two lines. With JkLogLevel set to debug, the following shows up in the mod_jk log: [Mon May 27 14:07:01 2002] [jk_uri_worker_map.c (447)]: Into jk_uri_worker_map_t::map_uri_to_worker [Mon May 27 14:07:01 2002] [jk_uri_worker_map.c (464)]: Attempting to map URI '/openroadTextFC.do' [Mon May 27 14:07:01 2002] [jk_uri_worker_map.c (529)]: jk_uri_worker_map_t::map_uri_to_worker, Found a suffix match web - *.do [Mon May 27 14:07:01 2002] [jk_uri_worker_map.c (447)]: Into jk_uri_worker_map_t::map_uri_to_worker [Mon May 27 14:07:01 2002] [jk_uri_worker_map.c (464)]: Attempting to map URI '/openroadTextFC.do' [Mon May 27 14:07:01 2002] [jk_uri_worker_map.c (529)]: jk_uri_worker_map_t::map_uri_to_worker, Found a suffix match web - *.do I add some extra debugging myself and ascertained that jk_translate runs through to completion, but no debugging code in jk_handler ever gets run. If jk_handler is entered at all it must fail at line 1075, const char *worker_name = ap_table_get(r-notes, JK_WORKER_ID); I've kind of shied away from trying to debug through apache. I didn't do the original build anyway. For any given URL that fails, it is possible to make it work again by making the URL *SHORTER*. This is possible if there is extraneous crap in the query string, which you can cut out. I have discovered that for a particular page (any one bad page will fail consistently) There will be a particular length of URL: An 86 character URL may work say, but an 87 character URL will fail. The useable length of URL will vary from page to page though, and I haven't seen any other pattern in it. My speculation is that it's the size of the request object or something, of which the URL is only a component. A bit woolly I admit, but it's all I've got. Part of my problem is that I don't really know in what order Apache calls methods from mod_jk, so I don't know if any other part of mod_jk is being run between jk_translate and jk_handler. I also don't know that it isn't Apache code that is falling over instead of mod_jk code. Also IANACP (I Am Not A C Programmer) - not really anyway. Mostly Java, and I've just started dabbling in C in incidental ways such as this. And I'm new to HP-UX as well. Can anyone maybe shed a little light on the Apache/mod_jk interface for me? A bit of a rundown on the order in which the methods are called would be useful. Also is there any Apache API or mod_jk API documentation online which I might not be aware of. And if anyone tells me that I need to start hacking the Apache code, I'll be very depressed. Thanks in advance, Bruce Ashton Java Developer Internet Application Development The Met Office http://www.metoffice.com/ ext. 4560 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9416] - Memory usage by Tomcat
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=9416. 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=9416 Memory usage by Tomcat --- Additional Comments From [EMAIL PROTECTED] 2002-05-27 15:20 --- Hi, The idea of going for such a test code was just out of desperation and only to try some small code with which we can get some help. Can u suggest some code we can try out? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: j-t-c/jk/ build.properties.sample: Incorrect Syntax???
Anthony W. Marino wrote:
On Monday 27 May 2002 09:48 am, Anthony W. Marino wrote:
In several places within j-t-c/jk/ build.properties.sample there are
assignment values using parentheses instead of brackets.
For example:
apr.home=$(apache2.home)
instead of:
apr.home=${apache2.home)
Ooops:
apr.home=${apache2.home}
Fixed thanks!
Anthony
Thank You,
Anthony
--
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]
DO NOT REPLY [Bug 9445] New: - HotSpot Virtual Machine Error, Internal Error
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=9445. 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=9445 HotSpot Virtual Machine Error, Internal Error Summary: HotSpot Virtual Machine Error, Internal Error Product: Tomcat 4 Version: 4.0 Beta 1 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When I add one html:errors struts tag, I get the following error using the following environment: JBoss-2.4.4 with Tomcat-4.0.1-beta and E:\java\jdk1.3 # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Error ID: 47454E45524154452F4F502D41500E435050084B # abnormal program termination Press any key to continue . . . I changed to jdk1.3.1_03 and I got a similar error: # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Error ID: 47454E45524154452F4F502D41500E4350500842 # # Problematic Thread: prio=5 tid=0x8f4db28 nid=0x6e8 runnable # Press any key to continue . . . Does anybody has a solution for this error? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9434] - Response Filters do not work with jsp:forward
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=9434. 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=9434 Response Filters do not work with jsp:forward [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-05-27 16:45 --- In the current version of the specification, the request dispatcher will not use filters. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: j-t-c/jk/ build.properties.sample: Incorrect Syntax???
Okie Dokie!!!
Anthony
Anthony W. Marino wrote:
On Monday 27 May 2002 09:48 am, Anthony W. Marino wrote:
In several places within j-t-c/jk/ build.properties.sample there are
assignment values using parentheses instead of brackets.
For example:
apr.home=$(apache2.home)
instead of:
apr.home=${apache2.home)
Ooops:
apr.home=${apache2.home}
Fixed thanks!
Anthony
Thank You,
Anthony
--
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]
Divorcing karma from CVS access? (Re: Vicious Abuse?)
On Sat, May 25, 2002 at 03:51:54PM +0100, Pier Fumagalli wrote: Jeff Turner [EMAIL PROTECTED] wrote: .. and thankful that people like Costin persevere in spite of rather vicious abuse. Vicious abuse? All I am proposing is to add greater flexibility to the freedom of those who are involved with the Jakarta project. I was objecting to unprovoked Costin-bashing outside tomcat-dev, not your proposal. People outside tomcat-dev may not understand why a PMC member deserved your comments ;P As for your proposal, a few thoughts: - AFAIK there is no requirement that a committer be a coder. See the definition on http://jakarta.apache.org/site/roles.html. An example: Diana Shannon voted as a Cocoon committer, for volunteering to coordinate docs: http://marc.theaimsgroup.com/?t=10189649374r=1w=2 - Your proposal redefined 'contributor' to include CVS access, and I think that will cause confusion with the existing, looser meaning. - (random thoughts..) The whole notion of defining a person's worth in terms of their CVS access seems backwards and wrong. The 'committer/non-committer' dividing line is an artifact of CVS's coarse-grained access control, and will disappear once we migrate to Subversion or whatever. It would be nice if there was a 'rating' system that didn't hijack the versioning system's terminology. Karma rated on a different scale to CVS access. Then there could be a one-way mapping, X karma - Y CVS access. The karma system could be something like advogato's (http://www.advogato.org/trust-metric.html http://www.advogato.org/person/). --Jeff -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
j-t-c/jk/native(2) build.xml: Global Server Property Initialization Issue
For example, the apache13.home property is set with too a generic/common directory location which should, 100% of the time, evaluate to true when checked with an available task (ie; target detect). This global assignment will only occur, of course, when one has purposely commented-out (indicating apache13 not available) or inadvertantly omitted that particular property from a properties file. Several possible solutions: 1) Initialize the property with a more specific dir path (ie; /usr/local/apache13 (see apache2.home intialization). Only issue here is if the user had several installs of apache13 including in the default path and intended to use another installation path. 2) Remove the global assignment and make it a prerequisite for the user to add this to a properties file which will always fail if not preset in a properties file. If you are going to setup global properties in build.xml maybe some conditional statements are in order, where applicable, to be more os specific/compliant. Or mabe os specific properties files that could be generated/used automatically? Thanks, Anthony -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: j-t-c/jk/native(2) build.xml: Global Server Property Initialization Issue
On Monday 27 May 2002 02:36 pm, Anthony W. Marino wrote: For example, the apache13.home property is set with too a generic/common directory location which should, 100% of the time, evaluate to true when checked with an available task (ie; target detect). Note that True is when running on *nix implementations. Anthony This global assignment will only occur, of course, when one has purposely commented-out (indicating apache13 not available) or inadvertantly omitted that particular property from a properties file. Several possible solutions: 1) Initialize the property with a more specific dir path (ie; /usr/local/apache13 (see apache2.home intialization). Only issue here is if the user had several installs of apache13 including in the default path and intended to use another installation path. 2) Remove the global assignment and make it a prerequisite for the user to add this to a properties file which will always fail if not preset in a properties file. If you are going to setup global properties in build.xml maybe some conditional statements are in order, where applicable, to be more os specific/compliant. Or mabe os specific properties files that could be generated/used automatically? Thanks, Anthony -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Proposal] Removing 64K limit in jasper 2
I've been giving this topic considerable thought for
the last month. Now that JSTL is getting close to
official release, performance may become a bigger
issue.
I've been evaluating JSTL and experimenting with using
it for complex rendering logic. From what I've seen,
the common pattern of usage tends to have a limited
number of tags, with a few tags use repeatedly. As
denis pointed out, the performance would improve,
though one other benefit is improved reliability.
In my early benchmarks with JMeter and JProbe, deeply
nested try/catch statements results in excessive GC,
which kills reliability and performance. The work
Denis and Kin-man did recently has improved
performance dramatically for pages with lots of tags.
I have noticed on long tests that memory usage slowly
creeps up until I get out of memory error.
reusing tags probably won't improve performance by
2-4x, but it should make deployments with JSTL tags
more stable.
--- Denis Benoit [EMAIL PROTECTED] wrote:
On Fri, 24 May 2002, Kin-Man Chung wrote:
Like Costin, I don't think that there would be much
performance penalty
by calling a private method. In fact, if we want to
reduce the number
of unnecessary calls, I have another idea... well
I have two ideas,
one of which is not related to the 64 K limit.
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 string);
it would greatly reduce the number of write()
calls. So it would
contribute, in a limited way to reduce the size
of the _jsp_service()
method. It would be sligthly faster, which is
not bad :) by reducing
the number of method calls.
I'm no expert on JSPTag specs, but a common pattern in
JSTL is the following:
c:set ..
c:choose
c:when test=${some_state}/c:out
value=my_value//c:when
/c:choose
/c:set
Would the jsp page compilation make the distinction
between c:out ... which print out a value and one
that is used in a variable?
2. This one has nothing to do with the size, it's
just something that I think
we should plan for: tag reuse. Some of the pages
that have a lot of tags,
do so because they have them in an HTML table. A
big page can reference
80 or so tags, but these tags can represent only
four or five distinct
types. It is not so difficult to find 80 tags in
a page, but it would be
difficult to find one with 80 _distinct_ tag
classes! Most of these tags
could be reused, that is we often call:
tag1 = new SomeTag();
tag1.doStartTag();
tag1.doEndTag();
tag1.release();
tag2 = new SomeTag();
tag2.doStartTag();
tag2.doEndTag();
tag2.release();
There is no real reason to create a new tag for
tag2, it could have
been replaced by:
tag1 = new SomeTag();
tag1.doStartTag();
tag1.doEndTag();
tag1.doStartTag();
tag1.doEndTag();
tag1.release();
Here is the relevant section of the JSP specs (I
know Kin-Man, you don't need
a reminder, but others might :):
public void release()
Called on a Tag handler to release state. The page
compiler guarantees
that JSP page implementation objects will invoke
this method on all tag
handlers, but there may be multiple invocations on
doStartTag and
doEndTag in between.
So, the specs seem to imply that tag reuse is
allowed.
Now, why do I brought about this second point, if it
is not relevant to the 64K
limit? Just that whatever the solution we'll take
to address the issue, it
should not make tag reuse impossible. I agree with
Kin-Man, Tag will take more
importance in the future of JSP pages. So we must
take whatever measures to
optimize them. Most tags won't see a big
performance boost from reuse, but some
tags can be pretty hefty, and for them, tag reuse
can be a big factor.
Now, there were two approach to the 64K problem.
Kin-Man proposed creating
methods for each custom tags, and Costin proposed a
state machine. I tend to
agree with Kin-Man for one account, at the current
state of the compiler,
Kin-Man's method could be done faster. I don't
think we should throw away
the state machine implementation, but I see it
more as a Jasper 3 / Tomcat 5
thing :) At that time, it could be further
investigated the benefits and
penalties of this approach. But if we choose to
delegate each tag to a method,
I think it would be important to leave the door open
to tag reuse, that is if we
do not implement it at the same time.
Comments?
--
Denis Benoit
[EMAIL PROTECTED]
Looking at the work on jasper recently and comparing
it to the older tag pooling in 3.3, I lean towards
using the state machine idea. Though it also has a
limit for high concurrency, but those situations
really
j-t-c/jk/native/ build.xml: OS Specific Includes Fail
You need to set the os specific property (ie; linux) using the condition
task as is done in j-t-c/jk/native2/ build.xml as follows:
Example snippet from j-t-c/jk/native2/ build.xml:
!-- What OS ( it'll determine the includes ) --
condition property=linux
equals arg1=${os.name} arg2=Linux/
/condition
condition property=solaris
equals arg1=${os.name} arg2=SunOS/
/condition
condition property=win32
os family=windows/
/condition
condition property=hpux
equals arg1=${os.name} arg2=HP-UX/
/condition
!-- I believe they are using cross-compilation, so checking the os.name
doesn't help. We'll check if the NDK is installed instead --
condition property=netware
available file=novellndk.home /
/condition
Thank You,
Anthony
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9434] - Response Filters do not work with jsp:forward
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=9434. 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=9434 Response Filters do not work with jsp:forward [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-05-27 21:43 --- Could you please provide any hints in the specification supporting this theory? Either, this is a lack in the implementation of spec 2.3, or the specification does not point out restrictions in the orthogonality of filters vs. JSP tags. Any article I have read regarding filters supports the impression filters are are technology to use on top of servlets JSP. Things work fine with Resin. I think the worst is declaring this lack internally as a silent restriction of Tomcat. Unless I have missed a clear hint in the specification, this has to be either mentioned in the release notes or fixed or pointed out in the specification. I aggree the specification might drop a note on wether filters should be bound to the destination URL or source URL on page forwards. However, dropping support for any use of filters with applications that use jsp:forward is weakening filters to a might work if you are lucky approach. I understand I am the guy postulating without giving. I've spent some hours trying to find a solution and failed. I'm not in the source. I'm using your great work without contribution. However, from a users perspective, this is simply arrogantly saying: Yes, you found a bug. But we will neither tell nor fix it. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_env.c
nacho 02/05/27 14:56:19
Modified:jk/native2/common jk_env.c
Log:
* Fixed build in win32
Thanks to Mladen Turk
Revision ChangesPath
1.29 +2 -1 jakarta-tomcat-connectors/jk/native2/common/jk_env.c
Index: jk_env.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_env.c,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- jk_env.c 24 May 2002 04:26:00 - 1.28
+++ jk_env.c 27 May 2002 21:56:19 - 1.29
@@ -58,6 +58,7 @@
#include jk_global.h
#include jk_env.h
#include jk_objCache.h
+#include apr_general.h
jk_env_t *jk_env_globalEnv;
void *jkGlobalAprPool;
@@ -72,7 +73,7 @@
/* Env management */
-static void JK_METHOD *jk2_env_getAprPool( jk_env_t *env ) {
+static void * JK_METHOD jk2_env_getAprPool( jk_env_t *env ) {
#ifdef HAS_APR
/* We don't want to have to recreate the scoreboard after
* restarts, so we'll create a global pool and never clean it.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_endpoint.c
nacho 02/05/27 14:57:45 Modified:jk/native2/common jk_endpoint.c Log: * Typos * initing stats object to NULL Revision ChangesPath 1.15 +2 -2 jakarta-tomcat-connectors/jk/native2/common/jk_endpoint.c Index: jk_endpoint.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_endpoint.c,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- jk_endpoint.c 16 May 2002 20:57:26 - 1.14 +++ jk_endpoint.c 27 May 2002 21:57:45 - 1.15 @@ -112,7 +112,7 @@ ep-stats-reqCnt=0; ep-stats-errCnt=0; -#ifdef HAVE_APR +#ifdef HAS_APR ep-stats-maxTime=0; ep-stats-totalTime=0; #endif @@ -149,7 +149,7 @@ e-sd=-1; e-recoverable=JK_TRUE; e-cPool=pool-create(env, pool, HUGE_POOL_SIZE ); - +e-stats = NULL; e-channelData = NULL; e-currentRequest = NULL; epId=atoi( result-localName ); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Proposal] Removing 64K limit in jasper 2
I am still in vacation mode, unil Thursday. Just want to giva some quick response. Like Costin, I don't think that there would be much performance penalty by calling a private method. In fact, if we want to reduce the number of unnecessary calls, I have another idea... well I have two ideas, one of which is not related to the 64 K limit. The performance hit comes not only from the extra calls, but also from the local instances (e.g. out and tagStack) that need to be passed to the methods. Also the increase in the number of methods in a class cannot be good to VM performance. Let's hope that Hotspot can do good job here. We'll have to see. 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 string); it would greatly reduce the number of write() calls. So it would contribute, in a limited way to reduce the size of the _jsp_service() method. It would be sligthly faster, which is not bad :) by reducing the number of method calls. This is actually in my plan. It would be relative easy to collapse consecutive writes. We should also consider the performance issues Costin raised, and maybe redo the runtime library to achieve better performance in writing out the String/char[] area. The key here is to avoid unnecessary copying. 2. This one has nothing to do with the size, it's just something that I think we should plan for: tag reuse. Some of the pages that have a lot of tags, do so because they have them in an HTML table. A big page can reference 80 or so tags, but these tags can represent only four or five distinct types. It is not so difficult to find 80 tags in a page, but it would be difficult to find one with 80 _distinct_ tag classes! Most of these tags could be reused, that is we often call: tag1 = new SomeTag(); tag1.doStartTag(); tag1.doEndTag(); tag1.release(); tag2 = new SomeTag(); tag2.doStartTag(); tag2.doEndTag(); tag2.release(); There is no real reason to create a new tag for tag2, it could have been replaced by: tag1 = new SomeTag(); tag1.doStartTag(); tag1.doEndTag(); tag1.doStartTag(); tag1.doEndTag(); tag1.release(); Here is the relevant section of the JSP specs (I know Kin-Man, you don't need a reminder, but others might :): public void release() Called on a Tag handler to release state. The page compiler guarantees that JSP page implementation objects will invoke this method on all tag handlers, but there may be multiple invocations on doStartTag and doEndTag in between. So, the specs seem to imply that tag reuse is allowed. Now, why do I brought about this second point, if it is not relevant to the 64K limit? Just that whatever the solution we'll take to address the issue, it should not make tag reuse impossible. I agree with Kin-Man, Tag will take more importance in the future of JSP pages. So we must take whatever measures to optimize them. Most tags won't see a big performance boost from reuse, but some tags can be pretty hefty, and for them, tag reuse can be a big factor. Believe it or not, tag reuse is also in my plan. I am in active discussion with Jan Leuhe in the very topic, and we'll have a proposal soon. Our scheme is very different from the one used in tomcat 3. We want to have a simple scheme that can reuse tag in the current page, especially tags in loops. More about this later. Therefore I would not do anything now that'll make doing tag reuse harder. :-) Now, there were two approach to the 64K problem. Kin-Man proposed creating methods for each custom tags, and Costin proposed a state machine. I tend to agree with Kin-Man for one account, at the current state of the compiler, Kin-Man's method could be done faster. I don't think we should throw away the state machine implementation, but I see it more as a Jasper 3 / Tomcat 5 thing :) At that time, it could be further investigated the benefits and penalties of this approach. But if we choose to delegate each tag to a method, I think it would be important to leave the door open to tag reuse, that is if we do not implement it at the same time. Interpreters with state machines may work well for scriptless pages, and would be an interesting project. It is however not my current focus for now. Comments? -- Denis Benoit [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Proposal] Removing 64K limit in jasper 2
I've been giving this topic considerable thought for the last month. Now that JSTL is getting close to official release, performance may become a bigger issue. I've been evaluating JSTL and experimenting with using it for complex rendering logic. From what I've seen, the common pattern of usage tends to have a limited number of tags, with a few tags use repeatedly. As denis pointed out, the performance would improve, though one other benefit is improved reliability. In my early benchmarks with JMeter and JProbe, deeply nested try/catch statements results in excessive GC, which kills reliability and performance. The work Denis and Kin-man did recently has improved performance dramatically for pages with lots of tags. I have noticed on long tests that memory usage slowly creeps up until I get out of memory error. The OOM errors may be caused because you have too many active sessions. reusing tags probably won't improve performance by 2-4x, but it should make deployments with JSTL tags more stable. I think you're pessimistic here. Depending on the page and the tags used (JDBC tags would kill throughtput, obvioulsy), it may be very significant. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9434] - Response Filters do not work with jsp:forward
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=9434. 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=9434 Response Filters do not work with jsp:forward [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-05-28 02:02 --- Bugzilla is not a place to post questions about the servlet API. Post on servlet interest instead. The servlet API 2.3 does not allow filters with RD. The servlet API 2.4 is likely to allow to specify to the RD wether or not you want filters. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9027] - The Tomcat Servlet Container use the identity specified in a servlet with the element run-as for every web component.
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=9027. 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=9027 The Tomcat Servlet Container use the identity specified in a servlet with the element run-as for every web component. [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|NEW -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
