Re: [VOTE] JK2 2.1
#ifdef AS400 fp = fopen(workerFile, w, o_ccsid=0); #else fp = fopen(workerFile, w); #endif Is this abstractive code enough ;) That was the initial price to have iSeries support in JK2. But that's rigth, I'll create a jk_os.c to hide this from main code (in both jk 1.2.0 and 2.0.0). But will still have to use ifdef with EBCDIC system (iSeries / BS2000), for example in JNI areas or request encoding/decoding. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] JK2 2.1
More comments on APR and JK2. While making tomcat-connectors rpm for jk2, and also jk2 binaries for Linux, I wanted to have apache 1.3 jk2 built with JNI support. JNI support in JK2 requires APR. So I build an apr 0.9.1 rpm, which include apr-utils since apr-utils couldn't be built without apr ;-[ To avoid conflict with Apache 2.0 rpms, I've installed apr libs in /usr/lib/apr/ and includes in /usr/include/apr. And here we allready discover many interesting things : With Apache 2.0, libapr shared lib in name libapr.so.0.9.2. With APR build, it's called libapr-0.so.0.9.2. What you see also is that is seems that parts of apr-utils are included in Apache2 binaries (ie md5 stuff), so when you're using APR libs, you should add apr and aprutils to ldpath (-lapr -laprutils). With that I was thinking being ready to make Apache 1.3 works with APR, for JNI use purposes. I've used : ./configure --with-apxs=/usr/sbin/apxs --with-jni --with-apr-lib=/usr/lib/apr --with-apr-include=/usr/include/apr The build works but I saw that the mod_jk2.so was linked against /usr/lib/libapr.so (the one from Apache 2.0 built) against the one in /usr/lib/arp. So I patched Makefile.in to change -lapr to -lapr-0. here correct build and link. But the JNI support was still not there since the Makefile.in need a little rework. I tried first to use and adapt the one from Apache 2.0 but this one didn't works since Apache 2.0.42 provide it's own libtool 1.4.2 and make use of rpath, which didn't works with the standard libtool 1.4 bundled with Redhat 7.2 No problem, I adapted the original Makefile.in from Apache 1.3 (patch attached) and do the build. I finally got a mod_jk2.so and jkjni.so to be used with my Apache 1.3. I installed mod_jk2.so and jkjni.so in Apache 1.3 modules dir, /usr/lib/apache, tried a restart but it failed with : Starting httpd: Syntax error on line 1536 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/mod_jk2.so into server: /etc/httpd/modules/mod_jk2.so: undefined symbol: jk_jni_status_code Urg, I think it could be related to missing stuff in mod_jk2.so, since it's not linked against apr-util shared lib, so I rechange the Makefile.in, does the configure and make. But still same error : Cannot load /etc/httpd/modules/mod_jk2.so into server: /etc/httpd/modules/mod_jk2.so: undefined symbol: jk_jni_status_code When I take a look at binaries, the jkjni.so for Apache 2 is 126180 long but the one for Apache 1.3 is only 8796 ? Here is was ldd -v report about mod_jk2.so / jkjni.so for Apache 1.3 and 2.0 : mod_jk2.so for Apache 1.3 libcrypt.so.1 = /lib/libcrypt.so.1 (0x4002f000) libapr-0.so.0 = /usr/lib/apr/libapr-0.so.0 (0x4005c000) libaprutil-0.so.0 = /usr/lib/apr/libaprutil-0.so.0 (0x4007a000) libc.so.6 = /lib/i686/libc.so.6 (0x4008f000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) Version information: /usr/lib/apache/mod_jk2.so: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.1) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/i686/libc.so.6 /lib/libcrypt.so.1: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/i686/libc.so.6 /usr/lib/apr/libapr-0.so.0: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.2) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.1.2) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.1) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/i686/libc.so.6 /usr/lib/apr/libaprutil-0.so.0: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.1) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/i686/libc.so.6 /lib/i686/libc.so.6: ld-linux.so.2 (GLIBC_2.1.1) = /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.2.3) = /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.1) = /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.2) = /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.0) = /lib/ld-linux.so.2 libcrypt.so.1 = /lib/libcrypt.so.1 (0x40012000) libapr-0.so.0 = /usr/lib/apr/libapr-0.so.0 (0x4003f000) libaprutil-0.so.0 = /usr/lib/apr/libaprutil-0.so.0 (0x4005d000) libc.so.6 = /lib/i686/libc.so.6 (0x40072000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) jkjni.so for Apache 1.3 Version information: /usr/lib/apache/jkjni.so: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/i686/libc.so.6 /lib/libcrypt.so.1: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/i686/libc.so.6 /usr/lib/apr/libapr-0.so.0: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6
Re: JK 1.2.1-beta
Glenn Nielsen wrote: You are currently working on mod_jk 1.2 and have done alot of work on the docs. Would you like to do it? We could add in the faq the common error messages and give an explanation. Idea, even put an url to the online documentation on jakarta ;-) I can do it if you can't, but I don't know when I would have the time. I'm pretty busy these days, and I was thinking releasing jk 1.2.1 since there was many fixes for iSeries, so jk 1.2.1 = jk 1.2.0 iSeries compatible. Adding better error messages informations could be planned for jk 1.2.2 even if I think we should concentrate on jk2 now ;-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jk 1.2.0 error reported on tomcat-user
Henri Gomez wrote: Someone has an idea of what could be the problem with ap_ctx-get ? It seems the user make use of ApacheToolbox. - This may add some info: I compiled Apache with ApacheToolbox. The modules are static but it has DSO support in it. Then again, I would expect an error much earlier in the load process then an undefined symbol. - I downloaded the binary of mod_jk.so from Jakarta's downloads in /builds/jakarta-tomcat-connectors/jk/release/v1.2.0/bin/linux/i386. I am running Apache 1.3.26 with Tomcat 4.05 on Red Hat Linux release 7.1 (Seawolf). The binary is compiled for 7.2, however. That may explain the following error when trying to start Apache: [root@dev bin]# ./apachectl configtest Syntax error on line 208 of /usr/local/apache-new/conf/httpd.conf: Cannot load /usr/local/apache-new/libexec/mod_jk.so into server: /usr/local/apache-new/libexec/mod_jk.so: undefined symbol: ap_ctx_get Any ideas? Do I need to upgrade gcc, possibly? What do the binaries rely upon? Sound eapi/noeapi problems. Thanks in advance, Ben Ricker -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] JK2 2.1
-Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 02, 2002 8:36 AM To: Tomcat Developers List Subject: Re: [VOTE] JK2 2.1 #ifdef AS400 fp = fopen(workerFile, w, o_ccsid=0); #else fp = fopen(workerFile, w); #endif Is this abstractive code enough ;) That was the initial price to have iSeries support in JK2. But that's rigth, I'll create a jk_os.c to hide this from main code (in both jk 1.2.0 and 2.0.0). OK. But will still have to use ifdef with EBCDIC system (iSeries / BS2000), for example in JNI areas or request encoding/decoding. No problem here, cause it's a channel component not a core one. MT -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.1.12 and Servlet Access 404 Errors: BUG? One Last Assurance
So I can understand, where is the difference in the code between Tomcat 4.1.10 and 4.1.12? And, do you mean that servlet mappings rather than being generic to some servlet/* path be individualized? At 12:26 PM 10/2/2002 +1000, you wrote: micael wrote: I cannot access a webapp with the normal http://localhost:8080/myapp/servlet/mydirectory.MyServlet with Tomcat 4.1.12. (Also, the embedded Tomcat 4.1.12 in JBoss 3.0.3 runs fine except that it won't access the examples servlets.) The error shown is a 404 The requested resource (/myapp/servlet/mydirectory.MyServlet) is not available.. The same thing runs fine with Tomcat 4.1.0., both with and without JBoss. Is this a BUG in Tomcat 4.1.12, or are there new constraints on reaching servlets from outside the container in 4.1.12? For security reasons (see the release notes for details), the invoker servlet is disabled by default now. This servlet is what makes /webapp/servlet/... paths invoke the given servlet. It's recommended that you give explicit servlet definitions and mappings in the webapps's web.xml instead. Michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JK 1.2.1-beta
Bojan Smojver wrote: On Tue, 2002-10-01 at 23:41, Glenn Nielsen wrote: Trying to interpret these error messages is a common question on tomcat-user. My proposal: 1. Change these errors messages so that they accurately identify what happened. 2. For these common errors only report one error rather than a series of three. 3. Add documentation to the mod_jk docs about what these errors mean. 2 sounds like quite a bit of work. yes, it's too much works 3 I think is a must (your e-mail is a great start for it - maybe you can whack it in FAQ). Yes, extend faq.xml/faq.html with error message. 1 would be nice, but people should be able to live with 3 if you don't have time for 1. Why not put an URL to faq.html, for the common error messages, ie : http://jakarta.apache.org/builds/jk/docs/faq.html#canconnect ? Up to date documentation could be provided like this ? What about same behaviour for jk2 ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] JK2 2.1
-Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 02, 2002 8:48 AM To: Tomcat Developers List Subject: Re: [VOTE] JK2 2.1 More comments on APR and JK2. Ok, I stopped here since I feel there is many works to conduct in JK2 to make Apache 1.3 compatible with APR/JNI. Man, you've done a great job. Conclusion, let's concentrate on JK2 now, make quickly a 2.0.1 release, which will have better support for APR/JNI with Apache 1.3 and will learn many things useable for JK 2.1. Agreed. mod_jk2 linux rpm and binaries will be released today but with Apache 1.3 WITHOUT APR/JNI support ;-) Excellent. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] JK2 2.1
Henri Gomez wrote: More comments on APR and JK2. While making tomcat-connectors rpm for jk2, and also jk2 binaries for Linux, I wanted to have apache 1.3 jk2 built with JNI support. JNI support in JK2 requires APR. So I build an apr 0.9.1 rpm, which include apr-utils since apr-utils couldn't be built without apr ;-[ To avoid conflict with Apache 2.0 rpms, I've installed apr libs in /usr/lib/apr/ and includes in /usr/include/apr. And here we allready discover many interesting things : With Apache 2.0, libapr shared lib in name libapr.so.0.9.2. With APR build, it's called libapr-0.so.0.9.2. What you see also is that is seems that parts of apr-utils are included in Apache2 binaries (ie md5 stuff), so when you're using APR libs, you should add apr and aprutils to ldpath (-lapr -laprutils). With that I was thinking being ready to make Apache 1.3 works with APR, for JNI use purposes. I've used : ./configure --with-apxs=/usr/sbin/apxs --with-jni --with-apr-lib=/usr/lib/apr --with-apr-include=/usr/include/apr The build works but I saw that the mod_jk2.so was linked against /usr/lib/libapr.so (the one from Apache 2.0 built) against the one in /usr/lib/arp. So I patched Makefile.in to change -lapr to -lapr-0. here correct build and link. That is not enough you should use apr-config. I have already patched mod_webapp for that. But the JNI support was still not there since the Makefile.in need a little rework. I tried first to use and adapt the one from Apache 2.0 but this one didn't works since Apache 2.0.42 provide it's own libtool 1.4.2 and make use of rpath, which didn't works with the standard libtool 1.4 bundled with Redhat 7.2 No problem, I adapted the original Makefile.in from Apache 1.3 (patch attached) and do the build. I finally got a mod_jk2.so and jkjni.so to be used with my Apache 1.3. I installed mod_jk2.so and jkjni.so in Apache 1.3 modules dir, /usr/lib/apache, tried a restart but it failed with : Starting httpd: Syntax error on line 1536 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/mod_jk2.so into server: /etc/httpd/modules/mod_jk2.so: undefined symbol: jk_jni_status_code Urg, I think it could be related to missing stuff in mod_jk2.so, since it's not linked against apr-util shared lib, so I rechange the Makefile.in, does the configure and make. But still same error : Cannot load /etc/httpd/modules/mod_jk2.so into server: /etc/httpd/modules/mod_jk2.so: undefined symbol: jk_jni_status_code When I take a look at binaries, the jkjni.so for Apache 2 is 126180 long but the one for Apache 1.3 is only 8796 ? Here is was ldd -v report about mod_jk2.so / jkjni.so for Apache 1.3 and 2.0 : mod_jk2.so for Apache 1.3 libcrypt.so.1 = /lib/libcrypt.so.1 (0x4002f000) libapr-0.so.0 = /usr/lib/apr/libapr-0.so.0 (0x4005c000) libaprutil-0.so.0 = /usr/lib/apr/libaprutil-0.so.0 (0x4007a000) libc.so.6 = /lib/i686/libc.so.6 (0x4008f000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) Version information: /usr/lib/apache/mod_jk2.so: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.1) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/i686/libc.so.6 /lib/libcrypt.so.1: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/i686/libc.so.6 /usr/lib/apr/libapr-0.so.0: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.2) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.1.2) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.1) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/i686/libc.so.6 /usr/lib/apr/libaprutil-0.so.0: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.1) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/i686/libc.so.6 /lib/i686/libc.so.6: ld-linux.so.2 (GLIBC_2.1.1) = /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.2.3) = /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.1) = /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.2) = /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.0) = /lib/ld-linux.so.2 libcrypt.so.1 = /lib/libcrypt.so.1 (0x40012000) libapr-0.so.0 = /usr/lib/apr/libapr-0.so.0 (0x4003f000) libaprutil-0.so.0 = /usr/lib/apr/libaprutil-0.so.0 (0x4005d000) libc.so.6 = /lib/i686/libc.so.6 (0x40072000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) jkjni.so for Apache 1.3 Version information: /usr/lib/apache/jkjni.so: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/i686/libc.so.6 /lib/libcrypt.so.1: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/i686/libc.so.6 /usr/lib/apr/libapr-0.so.0: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.2) =
Re: Tomcat 4.1.12 and Servlet Access 404 Errors: BUG?
I cannot see any difference relative to the invoker filter, ExampleFilter, in the web.xml for Tomcat 4.1.10 versus 4.1.12. Nothing seems to be commented out. I must be missing some point here. What is it? At 12:26 PM 10/2/2002 +1000, you wrote: For security reasons (see the release notes for details), the invoker servlet is disabled by default now. This servlet is what makes /webapp/servlet/... paths invoke the given servlet. It's recommended that you give explicit servlet definitions and mappings in the webapps's web.xml instead. Michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_webapp for Apache 2, Win32
[EMAIL PROTECTED] wrote: Hello, I'd like to setup Apache 2.0.42 + TomCat 4.1 with mod_webapp on Win NT. I found mod_webapp binary for Apache 1.3. It works fine. But Apache 2 requires another mod_webapp binary. I failed to find it on ASF web sites. I found only sources. I've downloaded jakarta-tomcat-connectors-4.1.12-src.zip. It contains readme.txt with following text: NO, IT DOES NOT RUN WITH WINDOWS (your images don't appear and the whole thing hangs?) AND SINCE I DON'T USE NEITHER POSSESS A MICROSOFT WINDOWS BASED MACHINE, THERE ARE NO CURRENT PLANS ON MAKING IT WORK OVER THERE (from my side). Does it mean that it cannot be compiled for Win NT? Or it means that mod_webapp can be compiled for Win NT, but it will work unstable? I tried to compile mod_webapp with Apache 2 sources. Compilation was successful. Only linking errors remained: mod_webapp.obj : error LNK2001: unresolved external symbol _wa_pool mod_webapp.obj : error LNK2001: unresolved external symbol _wa_cconnection mod_webapp.obj : error LNK2001: unresolved external symbol _wa_init mod_webapp.obj : error LNK2001: unresolved external symbol _wa_deploy mod_webapp.obj : error LNK2001: unresolved external symbol _wa_capplication mod_webapp.obj : error LNK2001: unresolved external symbol _wa_cvirtualhost mod_webapp.obj : error LNK2001: unresolved external symbol _wa_startup mod_webapp.obj : error LNK2001: unresolved external symbol _wa_shutdown mod_webapp.obj : error LNK2001: unresolved external symbol _wa_rfree mod_webapp.obj : error LNK2001: unresolved external symbol _wa_rinvoke mod_webapp.obj : error LNK2001: unresolved external symbol _wa_ralloc mod_webapp.obj : error LNK2001: unresolved external symbol _apr_filename_of_pathname Could smb. give me a hint how can I overcome this? Try with Linux. Or with cygwin. mod_webapp needs to be linked with several object in a dll. Or may be smb. could let me know where can I get mod_webapp binary for Apache 2? In the Internet I found a lot of similar questions. Many people want to get mod_webapp for Apache 2, but nobody can. It would be a good idea to make mod_webapp working under Win32 and put binaries on ASF site. Best regards, Alexander Klimuk ICQ 148557477 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.1.12 and Servlet Access 404 Errors: BUG?
Okay, I got it. It is in the conf/web.xml file. My searches for InvokerServlet were returning nothing. XP sucks. TextPad is not doing that well on this either. At 12:26 PM 10/2/2002 +1000, you wrote: For security reasons (see the release notes for details), the invoker servlet is disabled by default now. This servlet is what makes /webapp/servlet/... paths invoke the given servlet. It's recommended that you give explicit servlet definitions and mappings in the webapps's web.xml instead. Michael -- 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 12069] - Creation of more HttpSession objects for one previously timed out session
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=12069. 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=12069 Creation of more HttpSession objects for one previously timed out session --- Additional Comments From [EMAIL PROTECTED] 2002-10-02 07:34 --- Hey, what is this bug list for? If there is a bug report without any reaction for more than one month, there must be something wrong. At least a notice we know about this issue, but we will not fix it in 4.x would be polite. An example: When I have submitted a bug to a cURL bug list, the problem was fixed the same day. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.1.12 and Servlet Access 404 Errors: BUG?
micael wrote: I cannot see any difference relative to the invoker filter, ExampleFilter, in the web.xml for Tomcat 4.1.10 versus 4.1.12. Nothing seems to be commented out. I must be missing some point here. What is it? The invoker servlet, whilst still defined in 4.1.12, has no servlet-mapping defined for it in that version (it's commented out). All of this is in the default/fallback conf/web.xml Michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Ajp13 wrong Response
I found this post while researching the mail list archives for a problem
I am having. The description Henri provides sounds exactly like what is
happening with my application. I have included the original threads below.
Prior to reading this posting I had not come to Henri's conclusion:
Under certain conditions some request get the response for some other request
I was convinced my problem was related to how I was handling sessions,
or how Tomcat recycles them. But I have exhausted all resources I can
think of or find. This is the only thing I have found that comes close
to my problem. I will admit upfront that I am no expert in Tomcat
configuration.
Four or five users have contacted me with the same issue, which is
basically that when they login to my app they see data intended for
another user. Load is probably 40 to 50 concurrent users. I cannot
reproduce the problem and it seems to be very isolated, with only a few
occurences over the past week or so.
My environment is Red Hat Linux 7.2, Tomcat 3.3.1, Apache 1.3.22,
Postgres 7.1.3. User authentication is performed against Postgres and
userid is stored in a session attribute, along with a few other attributes.
In the 3.3.1 release notes bug 6234 was listed as resolved. I read the
contents of the bug and tried the TestServlet you provided to reproduce
the error. I still couldn't reproduce the problem which would make since
if I am running a version of Tomcat that is supposed to include the fix.
I also ran the TestServlet on 3.2.3 and couldn't reproduce. Although
nothing indicates that the bug existed prior to 3.3.
In the TestServlet you indicate that the workaround is to use
response.getOutputStream() instead of response.getWriter(). I am using
getOutputStream().
I realize that I may not have the same problem but would appreciate any
insight you could provide.
---Original Threads-
Actually, you don't need to load the system (that's the good news). It's
not a synchronization problem. It looks like it is a problem with error
handling, but I haven't tracked down where so I can't send a patch yet. It
seems that when you get an error, the writer gets stuck in it's last
successful request and always sends that one. I've reverted
HttpServletResponseFacade to always throwing away it's writer on recycle (so
that my developers can actually get work done) as a stop-gap and that seems
to have made it go away. Of course, this is far from ideal. What you need
to start seeing this is something like:
public class BadServlet extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {
PrintWriter out = response.getWriter();
out.println(Hello World);
throw new IOException(Hi Mom!);
}
}
- Original Message -
From: GOMEZ Henri [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, July 03, 2001 7:45 AM
Subject: RE: Ajp13 wrong Response
Very difficult to reproduce a situation under heavy load.
I stressed my Apache/TC with ab during nigths without
any failures but It was against simple servlets
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
-Original Message-
From: Angel Aray [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 03, 2001 2:46 PM
To: [EMAIL PROTECTED]
Subject: RE: Ajp13 wrong Response
I'll try that, but the problem I am seeing is with tomcat as late
as TC 3.3-M3.
-Original Message-
From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
Sent: Martes, 03 de Julio de 2001 04:10 a.m.
To: [EMAIL PROTECTED]
Subject: RE: Ajp13 wrong Response
I am having a problem which is very difficult to reproduce.
Under certain
conditions some request get the response for some other
request. It looks
like at some point probably due to some synchronization
issues tomcat
mixes de responses from different clients.
It was a known problem in early age of TC 3.3, with RequestDispatcher.
Could you try a fresh install of TC 3.3-M4 ?
I hadn't seen this behavior before, but since I moved from
using just
tomcat to using apache + mod_jk + tomcat it has occurred a couple of
times.
Has anyone seen this kind of behavior before?
I am using apache_1.3.20, tomcat33-m3.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] JK2 2.1
jean-frederic clere wrote: Henri Gomez wrote: More comments on APR and JK2. While making tomcat-connectors rpm for jk2, and also jk2 binaries for Linux, I wanted to have apache 1.3 jk2 built with JNI support. JNI support in JK2 requires APR. So I build an apr 0.9.1 rpm, which include apr-utils since apr-utils couldn't be built without apr ;-[ To avoid conflict with Apache 2.0 rpms, I've installed apr libs in /usr/lib/apr/ and includes in /usr/include/apr. And here we allready discover many interesting things : With Apache 2.0, libapr shared lib in name libapr.so.0.9.2. With APR build, it's called libapr-0.so.0.9.2. What you see also is that is seems that parts of apr-utils are included in Apache2 binaries (ie md5 stuff), so when you're using APR libs, you should add apr and aprutils to ldpath (-lapr -laprutils). With that I was thinking being ready to make Apache 1.3 works with APR, for JNI use purposes. I've used : ./configure --with-apxs=/usr/sbin/apxs --with-jni --with-apr-lib=/usr/lib/apr --with-apr-include=/usr/include/apr The build works but I saw that the mod_jk2.so was linked against /usr/lib/libapr.so (the one from Apache 2.0 built) against the one in /usr/lib/arp. So I patched Makefile.in to change -lapr to -lapr-0. here correct build and link. That is not enough you should use apr-config. I have already patched mod_webapp for that. Could you do the same for jk2, but it should be only if --with-apr is present... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Ajp13 wrong Response
Vince Clark wrote: I found this post while researching the mail list archives for a problem I am having. The description Henri provides sounds exactly like what is happening with my application. I have included the original threads below. Prior to reading this posting I had not come to Henri's conclusion: Under certain conditions some request get the response for some other request Hum, it came from prehistory ;-) With ajp13 and Tomcat 3.2.x, and should really be fixed with Tomcat 3.3.1. i didn't see such behaviour for months -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Ajp13 wrong Response
I have been turning over every stone I can find. Still no progress. I haven't ruled out a session problem but can't come up with a good way to reproduce the error. It would have to involve some way of accepting multiple cookies and making requests using each one. Do you know of any good documentation on how TC recycles sessions? I read a posting on the comp.lang.java newsgroup that eluded to the possibility of session attributes persisting in sessions that time out and are recycled. I also haven't ruled out a problem with my code, and it would make sense that this is where the problem lies since nobody else seems to be having any similar problems. Henri Gomez wrote: Vince Clark wrote: I found this post while researching the mail list archives for a problem I am having. The description Henri provides sounds exactly like what is happening with my application. I have included the original threads below. Prior to reading this posting I had not come to Henri's conclusion: Under certain conditions some request get the response for some other request Hum, it came from prehistory ;-) With ajp13 and Tomcat 3.2.x, and should really be fixed with Tomcat 3.3.1. i didn't see such behaviour for months -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Vince Clark Global Era, LLC Software, Database, and Web Solutions (303)433-4221 office (303)455-2409 fax [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] www.globalera.net -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12783] - Coyote Connector and HTTP 1.0 Keep-Alive
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=12783.
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=12783
Coyote Connector and HTTP 1.0 Keep-Alive
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
Status|RESOLVED|REOPENED
Resolution|INVALID |
Version|4.0.4 Final |4.1.12
--- Additional Comments From [EMAIL PROTECTED] 2002-10-02 09:00 ---
This is happening me with the coyote connector in Tomcat 4.1.12
Using a HTTP/1.0 client to POST a request using Keep-Alive, tomcat fails to
send the Connection: Keep-Alive header back to the client, although it does
indeed keep the connection open. While it is correct behavior for HTTP/1.1 to
omit the keep-alive response header, it is incorrect under HTTP/1.0
Changing the following in coyote's Http11Processor.java fixes it:
old:
if (!keepAlive) {
response.addHeader(Connection, close);
}
new:
if (!keepAlive) {
response.addHeader(Connection, close);
} else if (!http11) {
response.addHeader(Connection, Keep-Alive);
}
--ctwomey
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13194] New: - refreshing JSP containing a body tag gives problem on alternate refresh
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=13194.
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=13194
refreshing JSP containing a body tag gives problem on alternate refresh
Summary: refreshing JSP containing a body tag gives problem on
alternate refresh
Product: Tomcat 4
Version: 4.1.12
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Major
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
suspect that the release() is not executed after the taghandler instance's
lifecycle has ended.
to produce bug,
1. copy the tld file to webapp root.
2. compile the tag handler to webapp/WEB-INF/classes.
3. copy test.jsp to server and access it.
4. refresh the page(test.jsp), java.lang.ArrayIndexOutOfBoundsException will be
encountered on alternate browser refresh.
tld file
--
?xml version=1.0 encoding=ISO-8859-1 ?
!DOCTYPE taglib
PUBLIC -//Sun Microsystems, Inc.//DTD JSP Tag Library 1.1//EN
http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd;
taglib
tlibversion1.0/tlibversion
jspversion1.1/jspversion
shortnametest/shortname
info
A tag library for the pagination, product of Ecquaria Technologies Pte Ltd.
http://www.ecquaria.com/.
/info
tag
nameloop/name
tagclasstest.ArrayTag/tagclass
/tag
/taglib
Taghandler
---
package test;
import java.io.*;
import java.util.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;
import javax.servlet.jsp.tagext.*;
public class ArrayTag extends BodyTagSupport{
private BodyContent bodyContent;
private int index = -1;
private final int[] data = new int[] {0, 1, 2};
// tag support interface methods //
public void setBodyContent(BodyContent b) {
this.bodyContent = b;
}
/**
* Method called at start of Tag
* @return either a EVAL_BODY_TAG or a SKIP_BODY
*/
public int doStartTag() throws javax.servlet.jsp.JspException {
return EVAL_BODY_TAG;
}//doStartTag
//only only be called at most once
public void doInitBody() throws JspException {}
//@return EVAL_BODY_TAG, SKIP_BODY
public int doAfterBody() throws JspException{
++index;
System.out.print([ArrayTag] index: + index );
System.out.println(, current data: + data[index]);
return (indexdata.length-1) ? EVAL_BODY_TAG : SKIP_BODY;
}
/**
* Method called at end of Tag
* @return either EVAL_PAGE or SKIP_PAGE
*/
public int doEndTag() throws javax.servlet.jsp.JspException {
System.out.println(in doEndTag.);
return EVAL_PAGE; //to continue evaluating the rest of
the JSP.
}//doEndTag
/** Reset the state of the tag, to enable reuse of tag handler
instances. */
public void release() {
this.bodyContent = null;
this.index = -1;
super.release();
}//release
}//class ArrayTag
test.jsp
-
%@ taglib uri=/test.tld prefix=test%
%
int iii = 0;
System.out.println(\n\n-);
%
html
body
hi there!
test:loop
%
System.out.println(iii: + (iii++));
%
/test:loop
/body
/html
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[JK2] uriMap processing, need some opinions
Hi, Having some trouble clarifying uriMap processing. Situation 1: [uri:/examples/*] The context is / Situation 2: [uri:/examples/*] context=/ex The context is /ex Situation 3: [uri:/examples/*] context=/examples The context is /examples Now since all situations need the /examples/ as a prefix match, (to be able to sepate things like /examples/servlet/ uri with /examples/servlests/* mapping). We have a problem accesing /examples (without a trailing slash). The third situation can be solved returning context if no match is found and the uri equals to context. Is this right thing to do, and could it be used even before the prefixMatch?. The other two situations having context different then a uri could be solved by adding the trailing slash to the uri (in case there isnt one) and doing prefix match again. So: Situation 1 and 2: uriRequest /examples will find context '/' and no match, and since it doesn't ends with the trailing slash it will be added and we'll rerun prefixMatch returning /examples/ inside the root context. Situation 3: uriRequest /examples will find context '/examples' and no match, and since it doesn't ends with the trailing slash it will be added and we'll rerun prefixMatch returning /examples/ inside the '/examples' context. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_uriEnv.c
mturk 2002/10/02 02:45:02
Modified:jk/native2/common jk_uriEnv.c
Log:
Remove the APR code from the uriEnv.
Revision ChangesPath
1.34 +7 -52 jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c
Index: jk_uriEnv.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- jk_uriEnv.c 26 Sep 2002 12:29:17 - 1.33
+++ jk_uriEnv.c 2 Oct 2002 09:45:02 - 1.34
@@ -69,8 +69,6 @@
#include jk_uriMap.h
#include jk_registry.h
-#ifdef HAS_APR
-#include apr_uri.h
/** Parse the name:
VHOST/PATH
@@ -82,46 +80,6 @@
static int jk2_uriEnv_parseName( jk_env_t *env, jk_uriEnv_t *uriEnv,
char *name)
{
-
-apr_uri_t uri;
-char s[1024];
-
-/* If it uri starts with / then it is simple
- * default host uri
- */
-if (*name == '/')
-strcpy(s, name);
-else {
-strcpy(s, http://;);
-strcat(s, name);
-}
-env-l-jkLog(env, env-l, JK_LOG_DEBUG,
- uriEnv.parseName() uri %s name %s real %s\n,
- uriEnv-name, name, s);
-
-if (apr_uri_parse(uriEnv-pool-_private, s, uri) == APR_SUCCESS) {
-
-uriEnv-port = uri.port;
-if (uri.hostname) {
-if (!uriEnv-port)
-uriEnv-virtual = uri.hostname;
-else
-uriEnv-virtual = apr_pstrcat(uriEnv-pool-_private,
-uri.hostname, :, uri.port_str, NULL);
-}
-else
-uriEnv-virtual = *;
-uriEnv-uri = uri.path;
-if (!uri.path)
-uriEnv-match_type = MATCH_TYPE_HOST;
-return JK_OK;
-}
-return JK_ERR;
-}
-#else
-static int jk2_uriEnv_parseName( jk_env_t *env, jk_uriEnv_t *uriEnv,
- char *name)
-{
char *uri = NULL;
char *colon;
char host[1024];
@@ -162,7 +120,6 @@
return JK_OK;
}
-#endif /* HAS_APR */
static void * JK_METHOD jk2_uriEnv_getAttribute(jk_env_t *env, jk_bean_t *bean,
@@ -397,18 +354,16 @@
} else {
/* context based /context/prefix/ASTERISK */
asterisk[1] = '\0';
-#if 0
-asterisk[0] = '\0'; /* Remove the extra '/' */
-#endif
+
uriEnv-suffix = NULL;
uriEnv-prefix = uri;
uriEnv-prefix_len =strlen( uriEnv-prefix );
-uriEnv-match_type = MATCH_TYPE_PREFIX;
-if( uriEnv-mbean-debug 0 ) {
-env-l-jkLog(env, env-l, JK_LOG_DEBUG,
- uriEnv.init() prefix mapping %s=%s\n,
- uriEnv-prefix, uriEnv-workerName);
-}
+uriEnv-match_type = MATCH_TYPE_PREFIX;
+if( uriEnv-mbean-debug 0 ) {
+env-l-jkLog(env, env-l, JK_LOG_DEBUG,
+ uriEnv.init() prefix mapping %s=%s\n,
+ uriEnv-prefix, uriEnv-workerName);
+}
}
} else {
/* Something like : JkMount /servlets/exampl* ajp13 */
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_uriMap.c
mturk 2002/10/02 02:49:17
Modified:jk/native2/common jk_uriMap.c
Log:
1. Correct webapps for standalone context statements inside any uri
2. Add the contextMap (not sure if that is the correct name)
The contextMap purpose is to map the uri with the prefix without the prefixes
trailing slash, doing exact match. This allows mappings of /example if we
only have /example/* directive, but sill alowing /examle/ as a true prefix
match, not returning error for if we have /exam/* application too.
Revision ChangesPath
1.46 +190 -91 jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c
Index: jk_uriMap.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c,v
retrieving revision 1.45
retrieving revision 1.46
diff -u -r1.45 -r1.46
--- jk_uriMap.c 26 Sep 2002 12:29:17 - 1.45
+++ jk_uriMap.c 2 Oct 2002 09:49:16 - 1.46
@@ -171,14 +171,32 @@
if (uriLen uwr-prefix_len)
continue;
if (strncmp(uri, uwr-prefix, uwr-prefix_len) == 0) {
-if (uwr-prefix_len best_match) {
+if (uwr-prefix_len best_match) {
best_match=uwr-prefix_len;
-match=uwr;
+match=uwr;
}
}
}
return match;
}
+
+static jk_uriEnv_t *jk2_uriMap_contextMap(jk_env_t *env, jk_uriMap_t *uriMap,
+ jk_map_t *mapTable, const char *uri,
+ int uriLen)
+{
+int i;
+int sz = mapTable-size(env, mapTable);
+
+for (i = 0; i sz; i++) {
+jk_uriEnv_t *uwr = mapTable-valueAt(env, mapTable, i);
+if (uriLen != uwr-prefix_len - 1)
+continue;
+if (strncmp(uri, uwr-prefix, uriLen) == 0) {
+return uwr;
+}
+}
+return NULL;
+}
static jk_uriEnv_t *jk2_uriMap_exactMap(jk_env_t *env, jk_uriMap_t *uriMap,
jk_map_t *mapTable, const char *uri,
@@ -276,6 +294,151 @@
}
return uriMap-vhosts-get(env, uriMap-vhosts, *);
}
+
+static void jk2_uriMap_createHosts(jk_env_t *env, jk_uriMap_t *uriMap)
+{
+int i;
+
+for (i = 0; i uriMap-maps-size(env, uriMap-maps); i++) {
+jk_uriEnv_t *uriEnv = uriMap-maps-valueAt(env, uriMap-maps, i);
+if (uriEnv == NULL)
+continue;
+if (uriEnv-virtual != NULL strlen(uriEnv-virtual)) {
+if (uriEnv-match_type == MATCH_TYPE_HOST) {
+jk2_map_default_create(env, uriEnv-webapps, uriMap-pool);
+uriMap-vhosts-put(env, uriMap-vhosts,
+uriEnv-virtual, uriEnv, NULL);
+}
+else { /* Create the missing vhosts */
+if (!uriMap-vhosts-get(env, uriMap-vhosts,
+ uriEnv-virtual)) {
+jk2_map_default_create(env, uriEnv-webapps, uriMap-pool);
+uriMap-vhosts-put(env, uriMap-vhosts,
+uriEnv-virtual, uriEnv, NULL);
+
+env-l-jkLog(env, env-l, JK_LOG_DEBUG,
+ uriMap.init() Fixing Host %s\n,
+ uriEnv-virtual);
+}
+}
+}
+}
+
+/** Make sure each vhost has a default context
+ */
+for(i = 0; i uriMap-vhosts-size(env, uriMap-vhosts); i++) {
+jk_uriEnv_t *hostEnv = uriMap-vhosts-valueAt(env, uriMap-vhosts, i);
+jk_uriEnv_t *rootCtx;
+char *uriPath;
+
+if (hostEnv-virtual != NULL) {
+uriPath=env-tmpPool-calloc(env, env-tmpPool,
+ strlen(hostEnv-virtual) + 3);
+strcpy(uriPath, hostEnv-virtual);
+strcat(uriPath, /);
+} else {
+uriPath = /;
+}
+
+rootCtx = env-getByName2(env, uri, uriPath);
+if (rootCtx == NULL) {
+env-createBean2(env, uriMap-mbean-pool, uri, uriPath);
+rootCtx = env-getByName2(env, uri, uriPath);
+if (uriMap-mbean-debug 0)
+env-l-jkLog(env, env-l, JK_LOG_DEBUG,
+ uriMap.init() Create default context %s\n,
uriPath);
+rootCtx-mbean-setAttribute(env, rootCtx-mbean, context, /);
+}
+}
+}
+
+static void jk2_uriMap_createWebapps(jk_env_t *env, jk_uriMap_t *uriMap)
+{
+int i;
+
+/* Init all contexts */
+/* For each context, init the local uri maps */
+for (i = 0; i
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_uriEnv.c
mturk 2002/10/02 03:27:18
Modified:jk/native2/common jk_uriEnv.c
Log:
Add the context to the getAttribute, so we can display what is
the context of particular uri in the jkstatus
Revision ChangesPath
1.35 +7 -5 jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c
Index: jk_uriEnv.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- jk_uriEnv.c 2 Oct 2002 09:45:02 - 1.34
+++ jk_uriEnv.c 2 Oct 2002 10:27:17 - 1.35
@@ -104,10 +104,10 @@
uriEnv-virtual = uriEnv-pool-pstrdup(env, uriEnv-pool, host);
return JK_OK;
}
-if (colon) {
-*uri = '\0';
+*uri = '\0';
+if (colon)
uriEnv-port = atoi(colon);
-}
+
/* If it doesn't start with /, it must have a vhost */
if (strlen(host) uri != host) {
uriEnv-virtual = uriEnv-pool-calloc( env, uriEnv-pool, strlen(host) + 1
);
@@ -133,7 +133,9 @@
return uriEnv-uri;
} else if( strcmp( name, group )==0 ) {
return uriEnv-workerName;
-}
+} else if( strcmp( name, context )==0 ) {
+return uriEnv-contextPath;
+}
return NULL;
}
@@ -387,7 +389,7 @@
return JK_OK;
}
-static char *myAttInfo[]={ host, uri, group, NULL };
+static char *myAttInfo[]={ host, uri, group, context, NULL };
int JK_METHOD jk2_uriEnv_factory(jk_env_t *env, jk_pool_t *pool,
jk_bean_t *result,
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_uriMap.c
mturk 2002/10/02 03:28:36
Modified:jk/native2/common jk_uriMap.c
Log:
When creating 'free' webapps, put them to the correct vhost
changing to the real name composed of the host[:port]/context.
Revision ChangesPath
1.47 +12 -5 jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c
Index: jk_uriMap.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -r1.46 -r1.47
--- jk_uriMap.c 2 Oct 2002 09:49:16 - 1.46
+++ jk_uriMap.c 2 Oct 2002 10:28:36 - 1.47
@@ -415,16 +415,23 @@
strlen(context));
/* if not alredy created, create it */
if (ctxEnv == NULL) {
- jk_bean_t *mbean;
-
+jk_bean_t *mbean;
+char *ctxname;
+
+ctxname = uriEnv-pool-calloc(env, uriEnv-pool, strlen(vhost) +
+ strlen(context) + 1 );
+
+strcpy(ctxname, vhost);
+strcat(ctxname, context);
+
env-l-jkLog(env, env-l, JK_LOG_INFO,
- uriMap: creating context %s\n, context);
+ uriMap: creating context %s\n, ctxname);
mbean = env-getBean2(env, uri, context);
if (mbean == NULL)
-mbean = env-createBean2(env, uriMap-pool,uri, context);
+mbean = env-createBean2(env, uriMap-pool,uri, ctxname);
if (mbean == NULL || mbean-object == NULL) {
env-l-jkLog(env, env-l, JK_LOG_ERROR,
- uriMap: can't create context object %s\n,context);
+ uriMap: can't create context object %s\n,ctxname);
continue;
}
ctxEnv = mbean-object;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_uriMap.c
mturk 2002/10/02 03:58:06
Modified:jk/native2/common jk_uriMap.c
Log:
Fix the wrong uri association with the webaps.
If we specify the context in the uri, try the exactMap first cause webapp
can have a name that is subset of some larger context, so that larger one
would be used with the prefixMap only.
Revision ChangesPath
1.48 +18 -7 jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c
Index: jk_uriMap.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c,v
retrieving revision 1.47
retrieving revision 1.48
diff -u -r1.47 -r1.48
--- jk_uriMap.c 2 Oct 2002 10:28:36 - 1.47
+++ jk_uriMap.c 2 Oct 2002 10:58:06 - 1.48
@@ -487,7 +487,7 @@
jk_uriEnv_t *hostEnv = jk2_uriMap_hostMap(env, uriMap, vhost, port);
char *uri = uriEnv-uri;
-jk_uriEnv_t *ctxEnv;
+jk_uriEnv_t *ctxEnv = NULL;
if (hostEnv == NULL)
continue;
@@ -498,19 +498,30 @@
if (uri == NULL)
continue;
-
-ctxEnv = jk2_uriMap_prefixMap(env, uriMap, hostEnv-webapps, uri,
- strlen(uri));
+
+/* If the context was specified try to find the exact one */
+if (uriEnv-contextPath != NULL)
+ctxEnv = jk2_uriMap_exactMap(env, uriMap, hostEnv-webapps,
+ uriEnv-contextPath,
+ uriEnv-ctxt_len);
+/* Next find by uri prefix */
+if (ctxEnv == NULL)
+ctxEnv = jk2_uriMap_prefixMap(env, uriMap, hostEnv-webapps, uri,
+ strlen(uri));
if (ctxEnv == NULL) {
env-l-jkLog(env, env-l, JK_LOG_INFO,
uriMap.init() no context for %s\n, uri);
return JK_ERR;
-}
+}
+
+/* Correct the context path if needed */
uriEnv-contextPath = ctxEnv-prefix;
uriEnv-ctxt_len = ctxEnv-prefix_len;
-env-l-jkLog(env, env-l, JK_LOG_INFO,
- uriMap.init() adding context %s for %s\n,
ctxEnv-prefix, uri);
+
+if (uriMap-mbean-debug 5)
+env-l-jkLog(env, env-l, JK_LOG_INFO,
+ uriMap.init() adding context %s for %s\n,
ctxEnv-prefix, uri);
switch (uriEnv-match_type) {
case MATCH_TYPE_EXACT:
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[JK2] Unicode Log messages using 4.1.12
Hi, Since 4.1.12 I have the following messages in the jk2.properties.save \ua\up\ur\u.\uj\un\ui\uM\uo\ud\u e\uS\uo\u=\ui\un\up\ur\uo\uc\u00 00e\us\us\u \uc\uh\ua\un\un\ue\ul\uJ\un\ui\u .\ud\ui\us\ua\ub\ul\ue\ud\u=\u00 000\u maxThreads=75 \u\#\u\#\u=\uD\uO\uC\uU\uM\uE\uN \uT\uA\uT\uI\uO\uN\u \uO\uF\u \uT\uH\uE\u \uF\uO\uR\uM\uA\uT\u \uI\uN\u \uJ\uk\uM\ua\ui\un\u \uj\ua\uv\ua\ud\uo\uc\u.\u backlog=10 timeout=2 \u\#\u=\uT\uh\ui\us\u \uw\ui\ul\ul\u \ue\un\ua\ub\ul\ue\u \ut\uh\ue\u \us\ut\ua\ur\ut\ui\un\ug\u \uo\uf\u \ut\uh\ue\u \uT\uo\um\uc\ua\ut\u \uf\ur\uo\um\u \um\uo\ud\u_\uj\uk\u2\u tcpNoDelay=true \u= \u00FF\u00FE\#\u\#\u=\uT\uH\uI\uS\u \uF\uI\uL\uE\u \uM\uA\uY\u \uB\uE\u \uO\uV\uE\uR\uR\uI\uD\uE\uN\u \uA\uT\u \uR\uU\uN\uT\uI\uM\uE\u.\u \uM\uA\uK\uE\u \uS\uU\uR\uE\u \uT\uO\uM\uC\uA\uT\u \uI\uS\u \uS\uT\uO\uP\uE\uD\u And when starting tomcat the apr and channelJni log messages are also displayed using Unicode SEVERE: No class name for a p r a p r 2002.10.02 09:04:36 org.apache.jk.server.JkMain newHandler SEVERE: No class name for c h a n n e l J n i c h a n n e l J n i 2002.10.02 09:04:36 org.apache.jk.common.ChannelSocket init There was no such a promblems with the previous versions of TC. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Strange problem with tomcat 4.1.2
While working on 4.1.2 rpms I noticed the following error at startup : 4732 [main] INFO modeler.Registry - Creating MBeanServer 5705 [main] INFO http11.Http11Protocol - Initializing Coyote HTTP/1.1 on port 8080 Starting service Tomcat-Standalone Apache Tomcat/4.1 7324 [main] ERROR digester.Digester - Parse Fatal Error at line 307 column 39: The string -- is not permitted within comments. org.xml.sax.SAXParseException: The string -- is not permitted within comments. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source) at org.apache.xerces.impl.XMLScanner.scanComment(Unknown Source) at org.apache.xerces.impl.XMLDTDScannerImpl.scanComment(Unknown Source) at org.apache.xerces.impl.XMLDTDScannerImpl.scanDecls(Unknown Source) at org.apache.xerces.impl.XMLDTDScannerImpl.scanDTDExternalSubset(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse(Digester.java:1514) at org.apache.catalina.startup.ContextConfig.tldScanStream(ContextConfig.java:977) at org.apache.catalina.startup.ContextConfig.tldScanTld(ContextConfig.java:1006) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:870) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3493) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2189) at org.apache.catalina.startup.Catalina.start(Catalina.java:510) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) 8720 [main] ERROR digester.Digester - Parse Fatal Error at line 307 column 39: The string -- is not permitted within comments. org.xml.sax.SAXParseException: The string -- is not permitted within comments. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) Admin log show me the following error : 2002-10-02 13:29:01 WebappLoader[/admin]: Deploying class repositories to work directory /var/tomcat4/work/Standalone/localhost/admin 2002-10-02 13:29:01 WebappLoader[/admin]: Deploy class files /WEB-INF/classes to /var/tomcat4/webapps/../server/webapps/admin/WEB-INF/classes 2002-10-02 13:29:01 WebappLoader[/admin]: Deploy JAR /WEB-INF/lib/struts.jar to /var/tomcat4/webapps/../server/webapps/admin/WEB-INF/lib/struts.jar 2002-10-02 13:29:02 ContextConfig[/admin] Exception processing TLD at resource path /WEB-INF/controls.tld javax.servlet.ServletException: Exception processing TLD at resource path /WEB-INF/controls.tld at org.apache.catalina.startup.ContextConfig.tldScanTld(ContextConfig.java:1010) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:870) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3493) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:821) at
Re: [VOTE] JK2 2.1
Henri Gomez wrote: jean-frederic clere wrote: Henri Gomez wrote: More comments on APR and JK2. While making tomcat-connectors rpm for jk2, and also jk2 binaries for Linux, I wanted to have apache 1.3 jk2 built with JNI support. JNI support in JK2 requires APR. So I build an apr 0.9.1 rpm, which include apr-utils since apr-utils couldn't be built without apr ;-[ To avoid conflict with Apache 2.0 rpms, I've installed apr libs in /usr/lib/apr/ and includes in /usr/include/apr. And here we allready discover many interesting things : With Apache 2.0, libapr shared lib in name libapr.so.0.9.2. With APR build, it's called libapr-0.so.0.9.2. What you see also is that is seems that parts of apr-utils are included in Apache2 binaries (ie md5 stuff), so when you're using APR libs, you should add apr and aprutils to ldpath (-lapr -laprutils). With that I was thinking being ready to make Apache 1.3 works with APR, for JNI use purposes. I've used : ./configure --with-apxs=/usr/sbin/apxs --with-jni --with-apr-lib=/usr/lib/apr --with-apr-include=/usr/include/apr The build works but I saw that the mod_jk2.so was linked against /usr/lib/libapr.so (the one from Apache 2.0 built) against the one in /usr/lib/arp. So I patched Makefile.in to change -lapr to -lapr-0. here correct build and link. That is not enough you should use apr-config. I have already patched mod_webapp for that. Could you do the same for jk2, but it should be only if --with-apr is present... I will try. -- 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/native2/common jk_worker_jni.c
mturk 2002/10/02 05:48:26
Modified:jk/native2/common jk_worker_jni.c
Log:
We don't need the HAS_APR, cause we have HAVE_JNI.
Revision ChangesPath
1.28 +4 -8 jakarta-tomcat-connectors/jk/native2/common/jk_worker_jni.c
Index: jk_worker_jni.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_jni.c,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- jk_worker_jni.c 14 Jul 2002 13:33:56 - 1.27
+++ jk_worker_jni.c 2 Oct 2002 12:48:26 - 1.28
@@ -66,12 +66,10 @@
#include jk_workerEnv.h
#include jk_env.h
#include jk_bean.h
+
+#ifdef HAVE_JNI
-#ifdef HAS_APR
-#include apr_thread_proc.h
-#endif
-
-#ifdef HAVE_JNI
+#include apr_thread_proc.h
#include jk_vm.h
#include jk_registry.h
@@ -429,11 +427,9 @@
jniWorker-jk_main_method,
jargs);
if (jniWorker-hook == JK2_WORKER_HOOK_SHUTDOWN) {
-#ifdef HAS_APR
while (jk_jni_status_code != 2) {
apr_thread_yield();
}
-#endif
vm-detach(env, vm);
}
}
@@ -502,4 +498,4 @@
return JK_OK;
}
-#endif
+#endif
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_apr_socket.c
mturk 2002/10/02 05:50:05
Modified:jk/native2/common jk_channel_apr_socket.c
Log:
Enable connecting to other IP addreses of the same host
if the first one is down, checking all of them.
This is only the case when the specified server name is not
in the dot-ip notation.
Revision ChangesPath
1.26 +45 -41
jakarta-tomcat-connectors/jk/native2/common/jk_channel_apr_socket.c
Index: jk_channel_apr_socket.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_apr_socket.c,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- jk_channel_apr_socket.c 27 Sep 2002 13:07:28 - 1.25
+++ jk_channel_apr_socket.c 2 Oct 2002 12:50:05 - 1.26
@@ -219,51 +219,55 @@
apr_socket_t *sock=endpoint-channelData;
apr_status_t ret;
apr_int32_t timeout = (apr_int32_t)(socketInfo-timeout * APR_USEC_PER_SEC);
-char msg[128];
+char msg[128];
+int connected = 0;
+
+while (remote_sa !connected) {
+if ((ret = apr_socket_create(sock, remote_sa-family, SOCK_STREAM,
+ (apr_pool_t *)env-globalPool-_private))
+!= APR_SUCCESS) {
+env-l-jkLog(env, env-l, remote_sa-next ? JK_LOG_DEBUG :
JK_LOG_ERROR,
+ channelApr.open(): error %d creating socket %d %s\n,
+ ret, socketInfo-host);
+remote_sa = remote_sa-next;
+continue;
+}
+
-if (apr_socket_create(sock, remote_sa-family, SOCK_STREAM,
- (apr_pool_t *)env-globalPool-_private)
- != APR_SUCCESS) {
-env-l-jkLog(env, env-l, JK_LOG_ERROR,
- channelApr.open(): can't create socket %d %s\n,
- errno, strerror( errno ) );
-return JK_ERR;
-}
-env-l-jkLog(env, env-l, JK_LOG_INFO,
- channelApr.open(): create tcp socket %d\n, sock );
-
-/* the default timeout (0) will set the socket to blocking with
- infinite timeouts.
- */
-if (timeout = 0)
-timeout = -1;
-if (apr_setsocketopt(sock, APR_SO_TIMEOUT, timeout)!= APR_SUCCESS) {
-env-l-jkLog(env, env-l, JK_LOG_ERROR,
- channelApr.open(): can't set timeout %d %s\n,
- errno, strerror( errno ) );
-return JK_ERR;
-}
-
-/* Tries to connect to JServ (continues trying while error is EINTR) */
-do {
env-l-jkLog(env, env-l, JK_LOG_INFO,
- channelApr.open() connect on %d\n,sock);
-ret = apr_connect(sock, remote_sa);
-env-l-jkLog(env, env-l, JK_LOG_INFO,
- jk2_channel_apr_open: %d %s %s\n,ret, strerror( errno ),
- socketInfo-host);
-
-} while (ret == APR_EINTR);
+channelApr.open(): create tcp socket %d\n, sock );
+
+/* the default timeout (0) will set the socket to blocking with
+ infinite timeouts.
+*/
+if (timeout = 0)
+apr_socket_timeout_set(sock, 0);
+else
+apr_socket_timeout_set(sock, timeout);
+
+/* make the connection out of the socket */
+do {
+ret = apr_connect(sock, remote_sa);
+} while (APR_STATUS_IS_EINTR(ret));
+
+/* if an error occurred, loop round and try again */
+if (ret != APR_SUCCESS) {
+apr_socket_close(sock);
+env-l-jkLog(env, env-l, remote_sa-next ? JK_LOG_DEBUG :
JK_LOG_ERROR,
+ channelApr.open() attempt to connect to %pI (%s) failed
%d\n,
+ remote_sa,
+ socketInfo-host,
+ ret);
+remote_sa = remote_sa-next;
+continue;
+}
+connected = 1;
+}
-/* Check if we connected */
-if(ret != APR_SUCCESS ) {
-apr_socket_close(sock);
-env-l-jkLog(env, env-l, JK_LOG_ERROR,
- channelApr.open() connect failed %d %s\n,
- ret, apr_strerror( ret, msg, sizeof(msg) ) );
-return JK_ERR;
+if (!connected) {
+apr_socket_close(sock);
+return JK_ERR;
}
-
/* enable the use of keep-alive packets on TCP connection */
if(keepalive) {
int set = 1;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13069] - mod_webapp inits all webapps for each virtualHost
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=13069. 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=13069 mod_webapp inits all webapps for each virtualHost [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-02 13:25 --- Avoided by changing appBase and docBase in server.xml like this: Host name=webapp2.xxx.yyy debug=0 appBase=webapps/webapp2 Context path= docBase=. debug=255 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Need some clarifications
Hi So I worked myself through the various CVS sources and have a couple of official position questions to ask. The CVS projects jakarta-tomcat-catalina and jakarta-tomcat-jasper, will be forming the Tomcat 5 work? The CVS project jakarta-tomcat-4.0 is the 4.x branch? The CVS project jakarta-tomcat is anything before 4.0 The CVS project jakarta-tomcat-5.0 does nothing?? Thanks, for any help Christian Gross Software Engineering Consultant http://www.devspace.com North America: 1-450-675-4208 Europe +41.1.701.1166 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13205] New: - Tomcat Web Application Manager; config parameter is not null.
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=13205. 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=13205 Tomcat Web Application Manager; config parameter is not null. Summary: Tomcat Web Application Manager; config parameter is not null. Product: Tomcat 4 Version: 4.1.12 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina:Modules AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Trying to install a web application from the html manager I found out that if I don't specify the config URL a java.net.MalformedURLException is raised. This is because the method request.getParameter(config) called by the servlet org.apache.catalina.servlets.ManagerServlet returns a void string (i.e. '') instead of null. The consequence is that the constructor URL(String) throws that exception. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13206] New: - Invalid java bean property error message could be reported better.
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=13206.
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=13206
Invalid java bean property error message could be reported better.
Summary: Invalid java bean property error message could be
reported better.
Product: Tomcat 4
Version: 4.0.4 Final
Platform: PC
OS/Version: All
Status: NEW
Severity: Minor
Priority: Other
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Using an invalid Java bean that has setXXX and getXXX property methods that
have different in and out types can be difficult to track down. The error
message returned in such a case could be improved by including the property
type.
For example:
public class MyBeanClass {
MyViewClass mvc;
public void setView(String myViewClass) {
try {
mvc = (MyViewClass)Class.forName(myViewClass).newInstance();
} catch(Exception ex) {}
}
public MyViewClass getView() {
return myViewClass;
}
}
The problem with this java bean class is that the property 'view' has two
different types i.e. set takes a String but the get returns a MyViewClass
object.
If we use the following code in a JSP:-
jsp:useBean id=myBean class=MyBeanClass scope=application
jsp:setProperty name=myBean property=view value=MyViewClass/
/jsp:useBean
the following exception is thrown:-
org.apache.jasper.JasperException: Can't find a method to write property 'view'
in a bean of type 'MyBeanClass'
at org.apache.jasper.runtime.JspRuntimeLibrary.internalIntrospecthelper
(JspRuntimeLibrary.java)
at org.apache.jasper.runtime.JspRuntimeLibrary.introspecthelper
(JspRuntimeLibrary.java)
at org.apache.jsp.myJSP$jsp._jspService(myJSP$jsp.java)
If the type of the propery was printed out in the error message this would make
this mistake a lot easier to track down.
See line 714 in org.apache.jasper.runtime.JspRuntimeLibrary
private static void internalIntrospecthelper(Object bean, ...) ... {
...
if(type == null)
throw new JasperException(
Constants.getString(jsp.error.beans.noproperty,
new Object[] { prop, bean.getClass().getName()
}));
else
throw new JasperException(
Constants.getString(jsp.error.beans.nomethod.setproperty,
new Object[] { prop, bean.getClass().getName()
}));
...
}
The else part of the above code is been excecuted and even that the 'type' is
found it is not inserted into the exception.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JSP Compilation Problem: Tomcat 4.1.12
I posted this several days ago on tomcat-user and haven't gotten any responses so I am reposting it here. I am running into a problem with JSP pages under 4.1.12. I looked through the release notes, and the documentation and I can't find anything that seems to apply. Given a Servlet with the line: %@ page import=WebApp, CalServlet % where WebApp and CalServlet are classes in my application WEB-INF/classes directory that compiles under 4.0.4, when I try to run the servlet under 4.1.12, it crashes on compile with the following message: /usr/local/jakarta-tomcat-4.1.12/work/Standalone/localhost/caldev/index_jsp. java:7: '.' expected import WebApp; I turned on debugging, and the classpath looks correct: [javac] index_jsp.java added as /usr/local/jakarta-tomcat-4.1.12/work/Standalone/localhost/caldev/index_jsp. class doesn't exist. [javac] Compiling 1 source file [javac] Using modern compiler [javac] Compilation arguments: [javac] '-classpath' [javac] '/usr/java/lib/tools.jar:/usr/local/jakarta-tomcat-4.1.12/bin/bootstrap.jar: /home/gsexton/cdaily/WEB-INF/classes:/home/gsexton/cdaily/WEB-INF/lib/PNGEnc oder.jar:/home/gsexton/cdaily/WEB-INF/lib/activation.jar:/home/gsexton/cdail y/WEB-INF/lib/cryptix32.jar:/home/gsexton/cdaily/WEB-INF/lib/jdbc7.1-1.2.jar :/home/gsexton/cdaily/WEB-INF/lib/mail.jar:/usr/local/jakarta-tomcat-4.1.12/ shared/classes:/usr/local/jakarta-tomcat-4.1.12/common/classes:/usr/local/ja karta-tomcat-4.1.12/common/endorsed/xmlParserAPIs.jar:/usr/local/jakarta-tom cat-4.1.12/common/endorsed/xercesImpl.jar:/usr/local/jakarta-tomcat-4.1.12/c ommon/lib/activation.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/jasper- runtime.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/jasper-compiler.jar: /usr/local/jakarta-tomcat-4.1.12/common/lib/naming-resources.jar:/usr/local/ jakarta-tomcat-4.1.12/common/lib/commons-collections.jar:/usr/local/jakarta- tomcat-4.1.12/common/lib/naming-common.jar:/usr/local/jakarta-tomcat-4.1.12/ common/lib/commons-logging-api.jar:/usr/local/jakarta-tomcat-4.1.12/common/l ib/ant.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/mail.jar:/usr/local/j akarta-tomcat-4.1.12/common/lib/commons-dbcp.jar:/usr/local/jakarta-tomcat-4 .1.12/common/lib/servlet.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/jdb c2_0-stdext.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/commons-pool.jar :/usr/local/jakarta-tomcat-4.1.12/common/lib/jndi.jar:/usr/local/jakarta-tom cat-4.1.12/common/lib/naming-factory.jar:/usr/local/jakarta-tomcat-4.1.12/co mmon/lib/jta.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/MHS.jar:/usr/lo cal/jakarta-tomcat-4.1.12/common/lib/jdbc7.1-1.2.jar:/usr/local/jakarta-tomc at-4.1.12/common/lib/jconn2.jar' [javac] '-sourcepath' [javac] '/usr/local/jakarta-tomcat-4.1.12/work/Standalone/localhost/caldev' [javac] '-encoding' [javac] 'ISO-8859-1' [javac] '-g' [javac] [javac] The ' characters around the executable and arguments are [javac] not part of the command. [javac] File to be compiled: [javac] /usr/local/jakarta-tomcat-4.1.12/work/Standalone/localhost/caldev/index_jsp. java I tried this with Tomcat running as root and got the same result. I am using: java version 1.4.1 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21) Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode) On RedHat 7.2 w/ all patches applied. Any ideas on this would be appreciated. George Sexton MH Software, Inc. Home of Connect Daily Web Calendar Software http://www.mhsoftware.com/connectdaily.htm Voice: 303 438 9585 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Strange problem with tomcat 4.1.2
I BELIEVE that is due to some incorrect commenting in your server.xml file. I had this problem once and I thats what caused it. Double check your server.xml file. --- Henri Gomez [EMAIL PROTECTED] wrote: While working on 4.1.2 rpms I noticed the following error at startup : 4732 [main] INFO modeler.Registry - Creating MBeanServer 5705 [main] INFO http11.Http11Protocol - Initializing Coyote HTTP/1.1 on port 8080 Starting service Tomcat-Standalone Apache Tomcat/4.1 7324 [main] ERROR digester.Digester - Parse Fatal Error at line 307 column 39: The string -- is not permitted within comments. org.xml.sax.SAXParseException: The string -- is not permitted within comments. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source) at org.apache.xerces.impl.XMLScanner.scanComment(Unknown Source) at org.apache.xerces.impl.XMLDTDScannerImpl.scanComment(Unknown Source) at org.apache.xerces.impl.XMLDTDScannerImpl.scanDecls(Unknown Source) at org.apache.xerces.impl.XMLDTDScannerImpl.scanDTDExternalSubset(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse(Digester.java:1514) at org.apache.catalina.startup.ContextConfig.tldScanStream(ContextConfig.java:977) at org.apache.catalina.startup.ContextConfig.tldScanTld(ContextConfig.java:1006) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:870) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3493) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2189) at org.apache.catalina.startup.Catalina.start(Catalina.java:510) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) 8720 [main] ERROR digester.Digester - Parse Fatal Error at line 307 column 39: The string -- is not permitted within comments. org.xml.sax.SAXParseException: The string -- is not permitted within comments. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) Admin log show me the following error : 2002-10-02 13:29:01 WebappLoader[/admin]: Deploying class repositories to work directory /var/tomcat4/work/Standalone/localhost/admin 2002-10-02 13:29:01 WebappLoader[/admin]: Deploy class files /WEB-INF/classes to /var/tomcat4/webapps/../server/webapps/admin/WEB-INF/classes 2002-10-02 13:29:01 WebappLoader[/admin]: Deploy JAR /WEB-INF/lib/struts.jar to /var/tomcat4/webapps/../server/webapps/admin/WEB-INF/lib/struts.jar 2002-10-02 13:29:02 ContextConfig[/admin] Exception processing TLD at resource path /WEB-INF/controls.tld javax.servlet.ServletException: Exception processing TLD at resource path /WEB-INF/controls.tld at org.apache.catalina.startup.ContextConfig.tldScanTld(ContextConfig.java:1010) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:870) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) at
DO NOT REPLY [Bug 10565] - shutdown hook problem: java.lang.NoClassDefFoundError: java/util/Iterator
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=10565. 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=10565 shutdown hook problem: java.lang.NoClassDefFoundError: java/util/Iterator [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2002-10-02 14:57 --- I have searched through the servlet spec and it doesn't restrict the usage of threads and shutdown hooks in servlets. Anyway the problem here seems to be the (webapp)Classloader which throws a ClassNotFoundException if it is stopped. Isn't it possible to delegate the loading of classes to its parents when it is in shutdown mode? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSP Compilation Problem: Tomcat 4.1.12
if you're using jdk 1.4, you have to have package names for your classes. If you do not, it won't load the class correctly. have you tried giving your classes a package name and trying it again? peter Sexton, George wrote: I posted this several days ago on tomcat-user and haven't gotten any responses so I am reposting it here. I am running into a problem with JSP pages under 4.1.12. I looked through the release notes, and the documentation and I can't find anything that seems to apply. Given a Servlet with the line: %@ page import=WebApp, CalServlet % where WebApp and CalServlet are classes in my application WEB-INF/classes directory that compiles under 4.0.4, when I try to run the servlet under 4.1.12, it crashes on compile with the following message: /usr/local/jakarta-tomcat-4.1.12/work/Standalone/localhost/caldev/index_jsp. java:7: '.' expected import WebApp; I turned on debugging, and the classpath looks correct: [javac] index_jsp.java added as /usr/local/jakarta-tomcat-4.1.12/work/Standalone/localhost/caldev/index_jsp. class doesn't exist. [javac] Compiling 1 source file [javac] Using modern compiler [javac] Compilation arguments: [javac] '-classpath' [javac] '/usr/java/lib/tools.jar:/usr/local/jakarta-tomcat-4.1.12/bin/bootstrap.jar: /home/gsexton/cdaily/WEB-INF/classes:/home/gsexton/cdaily/WEB-INF/lib/PNGEnc oder.jar:/home/gsexton/cdaily/WEB-INF/lib/activation.jar:/home/gsexton/cdail y/WEB-INF/lib/cryptix32.jar:/home/gsexton/cdaily/WEB-INF/lib/jdbc7.1-1.2.jar :/home/gsexton/cdaily/WEB-INF/lib/mail.jar:/usr/local/jakarta-tomcat-4.1.12/ shared/classes:/usr/local/jakarta-tomcat-4.1.12/common/classes:/usr/local/ja karta-tomcat-4.1.12/common/endorsed/xmlParserAPIs.jar:/usr/local/jakarta-tom cat-4.1.12/common/endorsed/xercesImpl.jar:/usr/local/jakarta-tomcat-4.1.12/c ommon/lib/activation.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/jasper- runtime.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/jasper-compiler.jar: /usr/local/jakarta-tomcat-4.1.12/common/lib/naming-resources.jar:/usr/local/ jakarta-tomcat-4.1.12/common/lib/commons-collections.jar:/usr/local/jakarta- tomcat-4.1.12/common/lib/naming-common.jar:/usr/local/jakarta-tomcat-4.1.12/ common/lib/commons-logging-api.jar:/usr/local/jakarta-tomcat-4.1.12/common/l ib/ant.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/mail.jar:/usr/local/j akarta-tomcat-4.1.12/common/lib/commons-dbcp.jar:/usr/local/jakarta-tomcat-4 .1.12/common/lib/servlet.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/jdb c2_0-stdext.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/commons-pool.jar :/usr/local/jakarta-tomcat-4.1.12/common/lib/jndi.jar:/usr/local/jakarta-tom cat-4.1.12/common/lib/naming-factory.jar:/usr/local/jakarta-tomcat-4.1.12/co mmon/lib/jta.jar:/usr/local/jakarta-tomcat-4.1.12/common/lib/MHS.jar:/usr/lo cal/jakarta-tomcat-4.1.12/common/lib/jdbc7.1-1.2.jar:/usr/local/jakarta-tomc at-4.1.12/common/lib/jconn2.jar' [javac] '-sourcepath' [javac] '/usr/local/jakarta-tomcat-4.1.12/work/Standalone/localhost/caldev' [javac] '-encoding' [javac] 'ISO-8859-1' [javac] '-g' [javac] [javac] The ' characters around the executable and arguments are [javac] not part of the command. [javac] File to be compiled: [javac] /usr/local/jakarta-tomcat-4.1.12/work/Standalone/localhost/caldev/index_jsp. java I tried this with Tomcat running as root and got the same result. I am using: java version 1.4.1 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21) Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode) On RedHat 7.2 w/ all patches applied. Any ideas on this would be appreciated. George Sexton MH Software, Inc. Home of Connect Daily Web Calendar Software http://www.mhsoftware.com/connectdaily.htm Voice: 303 438 9585 -- 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: JSP Compilation Problem: Tomcat 4.1.12
I'm confused by the change in behavior. I can use JDK 1.4 w/ Tomcat 4.0.4 and it works. -Original Message- From: peter lin [mailto:[EMAIL PROTECTED]] Sent: 02 October, 2002 8:56 AM To: Tomcat Developers List Subject: Re: JSP Compilation Problem: Tomcat 4.1.12 if you're using jdk 1.4, you have to have package names for your classes. If you do not, it won't load the class correctly. have you tried giving your classes a package name and trying it again? peter Sexton, George wrote: I posted this several days ago on tomcat-user and haven't gotten any responses so I am reposting it here. I am running into a problem with JSP pages under 4.1.12. I looked through the release notes, and the documentation and I can't find anything that seems to apply. Given a Servlet with the line: %@ page import=WebApp, CalServlet % where WebApp and CalServlet are classes in my application WEB-INF/classes directory that compiles under 4.0.4, when I try to run the servlet under 4.1.12, it crashes on compile with the following message: /usr/local/jakarta-tomcat-4.1.12/work/Standalone/localhost/caldev/index_jsp. java:7: '.' expected import WebApp; I turned on debugging, and the classpath looks correct: -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] JK2 2.1
Henri Gomez wrote: More comments on APR and JK2. While making tomcat-connectors rpm for jk2, and also jk2 binaries for Linux, I wanted to have apache 1.3 jk2 built with JNI support. Do you have a multithreaded apache1.3 ? It's very important to compile it as multithreaded and link pthread ! For the apr issues - I still think that apr should be treated as a general-purpose library, and we shouldn't have more than one varaiant in the system. Probably some APR expert could clarify this - but my opinion is that on linux the right place for apr is /usr/lib/libapr.so.0.9.2 and /usr/include/apr. And I think Apache2.0 RPM should just depend on libapr.rpm, and same for mod_jk2.rpm It's just too confusing to have 2 variants of the same library, and it should be a portability library that can be used outside apache - without apache having a special copy. Costin JNI support in JK2 requires APR. So I build an apr 0.9.1 rpm, which include apr-utils since apr-utils couldn't be built without apr ;-[ To avoid conflict with Apache 2.0 rpms, I've installed apr libs in /usr/lib/apr/ and includes in /usr/include/apr. And here we allready discover many interesting things : With Apache 2.0, libapr shared lib in name libapr.so.0.9.2. With APR build, it's called libapr-0.so.0.9.2. What you see also is that is seems that parts of apr-utils are included in Apache2 binaries (ie md5 stuff), so when you're using APR libs, you should add apr and aprutils to ldpath (-lapr -laprutils). With that I was thinking being ready to make Apache 1.3 works with APR, for JNI use purposes. I've used : ./configure --with-apxs=/usr/sbin/apxs --with-jni --with-apr-lib=/usr/lib/apr --with-apr-include=/usr/include/apr The build works but I saw that the mod_jk2.so was linked against /usr/lib/libapr.so (the one from Apache 2.0 built) against the one in /usr/lib/arp. So I patched Makefile.in to change -lapr to -lapr-0. here correct build and link. But the JNI support was still not there since the Makefile.in need a little rework. I tried first to use and adapt the one from Apache 2.0 but this one didn't works since Apache 2.0.42 provide it's own libtool 1.4.2 and make use of rpath, which didn't works with the standard libtool 1.4 bundled with Redhat 7.2 No problem, I adapted the original Makefile.in from Apache 1.3 (patch attached) and do the build. I finally got a mod_jk2.so and jkjni.so to be used with my Apache 1.3. I installed mod_jk2.so and jkjni.so in Apache 1.3 modules dir, /usr/lib/apache, tried a restart but it failed with : Starting httpd: Syntax error on line 1536 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/mod_jk2.so into server: /etc/httpd/modules/mod_jk2.so: undefined symbol: jk_jni_status_code Urg, I think it could be related to missing stuff in mod_jk2.so, since it's not linked against apr-util shared lib, so I rechange the Makefile.in, does the configure and make. But still same error : Cannot load /etc/httpd/modules/mod_jk2.so into server: /etc/httpd/modules/mod_jk2.so: undefined symbol: jk_jni_status_code When I take a look at binaries, the jkjni.so for Apache 2 is 126180 long but the one for Apache 1.3 is only 8796 ? Here is was ldd -v report about mod_jk2.so / jkjni.so for Apache 1.3 and 2.0 : mod_jk2.so for Apache 1.3 libcrypt.so.1 = /lib/libcrypt.so.1 (0x4002f000) libapr-0.so.0 = /usr/lib/apr/libapr-0.so.0 (0x4005c000) libaprutil-0.so.0 = /usr/lib/apr/libaprutil-0.so.0 (0x4007a000) libc.so.6 = /lib/i686/libc.so.6 (0x4008f000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) Version information: /usr/lib/apache/mod_jk2.so: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.1) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/i686/libc.so.6 /lib/libcrypt.so.1: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/i686/libc.so.6 /usr/lib/apr/libapr-0.so.0: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.2) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.1.2) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.1) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/i686/libc.so.6 /usr/lib/apr/libaprutil-0.so.0: libc.so.6 (GLIBC_2.1.3) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.1) = /lib/i686/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/i686/libc.so.6 /lib/i686/libc.so.6: ld-linux.so.2 (GLIBC_2.1.1) = /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.2.3) = /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.1) = /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.2) = /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.0) = /lib/ld-linux.so.2 libcrypt.so.1 = /lib/libcrypt.so.1 (0x40012000) libapr-0.so.0 = /usr/lib/apr/libapr-0.so.0 (0x4003f000) libaprutil-0.so.0 = /usr/lib/apr/libaprutil-0.so.0 (0x4005d000) libc.so.6 = /lib/i686/libc.so.6 (0x40072000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) jkjni.so for Apache 1.3 Version information: /usr/lib/apache/jkjni.so:
A survey about handling bugs in open source projects
Hello all Tomcat contributors, I am conducting a survey about the way defects (or bugs-I use these two words interchangeably) are handled in open source software projects. It is very easy to fill out. It consists of three short sections which can be completed at once or in different sessions. The survey can be found in the address: http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html This survey includes questions that can be answered by developers,testers, bug fixers, bug database owners, and project managers. I would greatly appreciate if you could visit the above web page and fill out the survey. I am sure you will find the questions very interesting and thought provoking. We need the help of all contributors of Tomcat in the above roles to understand how we can use bugs data collected in your project for software engineering research. Nowadays, there is a huge amount of bug data on the Internet collected during the development of all open source products. A bug database include useful information to identify high-risk, problem-prone modules (components) in the software. It is also possible to measure these problem-prone components using several complexity metrics (McCabe's cyclomatic complexity, Halstead's metrics, etc.), since the source code is available. If a characterization, which is generalizable across many projects (sub-projects) could be made in terms of complexity, focused quality improvement would become possible in the future projects. So far, in the literature, there is quite amount of evidence that 80 percent of the problems occur from 20 percent of the modules (or software components), which gives hope toward tremendous quality increase, time savings, and increased success in the open source projects. Also a bug database includes useful information about the efficiency of development. For example, if a lot of bugs related to design of the system are found after release, when coding bugs are expected more, then this may indicate that the design or architecture of the system was done cursory. Of course, these kinds of conclusions would require some kind of classification of bugs according to their insertion time after they get fixed. However, before trying to find an answer to the questions like above, our first step is to understand if the available data is usable for empirical research purposes. This means having an idea about the consistency of bug reports and fixes, accuracy of data, completeness of the data, etc. At this point, we need your help. By filling out this survey, you will help us understand availability, representativeness, and characteristics of the data in the bug database of your project. I'd like to stress that the purpose of this survey is only and only research. Open source development gained a very good momentum in the last decade. We hope that outcomes of our research will help even increase this momentum. We will acknowledge the help of all supporting communities when mentioning our results. In addition to these goals, we also think that filling out this short survey can lead to some immediate brain-storming in individuals and groups, and exchange of ideas among the Tomcat community, which will be useful too. As I said, you will find the survey questions interesting. If you'd prefer to learn more about our research, I included a link in the above web page of our survey. This link provides more information about our research. Once more, your contribution is very important to us. Please visit http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html and fill out our survey. We greatly appreciate your helps. Please contact me for any question you might have. Thanks -- *** A. Gunes Koru Research Assistant, Ph.D. Student Southern Methodist University Computer Science and Engineering Department 6425 North Ownby Drive Science and Information Building Room 317 Dallas, TX 75205 Home: 214 691 5633 Work: 214 768 2005 Cell: 214 893 7311 http://www.seas.smu.edu/~gkoru Email: [EMAIL PROTECTED] *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JSP Compilation Problem: Tomcat 4.1.12
Never mind. I found this described in Bug #10036. -Original Message- From: Sexton, George [mailto:[EMAIL PROTECTED]] Sent: 02 October, 2002 9:03 AM To: Tomcat Developers List Subject: RE: JSP Compilation Problem: Tomcat 4.1.12 I'm confused by the change in behavior. I can use JDK 1.4 w/ Tomcat 4.0.4 and it works. -Original Message- From: peter lin [mailto:[EMAIL PROTECTED]] Sent: 02 October, 2002 8:56 AM To: Tomcat Developers List Subject: Re: JSP Compilation Problem: Tomcat 4.1.12 if you're using jdk 1.4, you have to have package names for your classes. If you do not, it won't load the class correctly. have you tried giving your classes a package name and trying it again? peter Sexton, George wrote: I posted this several days ago on tomcat-user and haven't gotten any responses so I am reposting it here. I am running into a problem with JSP pages under 4.1.12. I looked through the release notes, and the documentation and I can't find anything that seems to apply. Given a Servlet with the line: %@ page import=WebApp, CalServlet % where WebApp and CalServlet are classes in my application WEB-INF/classes directory that compiles under 4.0.4, when I try to run the servlet under 4.1.12, it crashes on compile with the following message: /usr/local/jakarta-tomcat-4.1.12/work/Standalone/localhost/caldev/index_jsp. java:7: '.' expected import WebApp; I turned on debugging, and the classpath looks correct: -- 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]
[Possible bug with jspc]
I spent the last two days trying to use JspC to compile an entire webapp and came across a problem. I'm not sure if this is a bug or not, but I can reproduce it every time. I'm still trying to track down the cause, but I thought I'd post a question and maybe some one with more knowledge can point me in the right direction. I am using the following command to run jspc C:\tomcat\binjspc -d ..\work\Standalone\localhost\_ -uribase c:/myapp/web -webapp c:/myapp/web in one of included files I define all the taglibs i use. right now I am using taglibs from the Jakarta. If I use the string tag, it causes JspC to die with NPE. If I remove the %@ taglib % for string tag, jspc works fine. the main difference between JSTL and string tag is JSTL is 1.2 and string tag is 1.1. the page works just fine if I load it in the browser, but for some reason, JspC doesn't like 1.1 taglibs. can anyone provide any insight? peter lin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
mturk 2002/10/02 08:36:22
Modified:jk/native2/common jk_worker_lb.c
Log:
Introduced 3 new configuration parameters to the lb.
1. attempts -- replaces harcoded MAX_ATTEMPTS
2. recovery -- replaces hardcoded WAIT_BEFORE_RECOVER
3. timeout -- this one is new.
The timeout if set will force the lb to cycle through workers if all are in the
error_state for the specified amount of seconds. This is usefull for
situations when the TC is overloaded and refuses new connections.
The lb will wait and after timeout will report 500 to the client.
Revision ChangesPath
1.24 +36 -9 jakarta-tomcat-connectors/jk/native2/common/jk_worker_lb.c
Index: jk_worker_lb.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_lb.c,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- jk_worker_lb.c8 Jul 2002 13:33:38 - 1.23
+++ jk_worker_lb.c2 Oct 2002 15:36:22 - 1.24
@@ -77,15 +77,20 @@
#define DEFAULT_LB_FACTOR (1.0)
/* Time to wait before retry... XXX make it configurable*/
-#define WAIT_BEFORE_RECOVER (60)
+#define WAIT_BEFORE_RECOVER 60
#define MAX_ATTEMPTS 3
#define NO_WORKER_MSG The servlet container is temporary unavailable or being
upgraded\n;
typedef struct {
-struct jk_mutex *cs;
-intinitializing;
+struct jk_mutex *cs;
+int initializing;
+int attempts;
+int recovery;
+int timeout;
+time_t error_time;
+
} jk_worker_lb_private_t;
/** Find the best worker. In process, check if timeout expired
@@ -108,6 +113,7 @@
int currentLevel=JK_LB_LEVELS - 1;
char *session_route;
time_t now = 0;
+jk_worker_lb_private_t *lb_priv = lb-worker_private;
session_route = jk2_requtil_getSessionRoute(env, s);
@@ -119,7 +125,7 @@
if(w-route != NULL
0 == strcmp(session_route, w-route)) {
if(attempt 0 w-in_error_state) {
-/* We already tried to revive this worker. */
+/* We already tried to revive this worker. */
break;
} else {
return w;
@@ -181,7 +187,7 @@
/* Check if it's ready for recovery */
if( now==0 ) now = time(NULL);
-if((now - w-error_time) WAIT_BEFORE_RECOVER) {
+if((now - w-error_time) lb_priv-recovery) {
env-l-jkLog(env, env-l, JK_LOG_ERROR,
lb.getWorker() reenable %s\n, w-mbean-name);
w-in_error_state = JK_FALSE;
@@ -331,7 +337,18 @@
rec=jk2_get_most_suitable_worker(env, lb, s, attempt);
if (lb_priv-cs != NULL)
-lb_priv-cs-unLock(env, lb_priv-cs);
+lb_priv-cs-unLock(env, lb_priv-cs);
+if (!rec lb_priv-timeout) {
+time_t now = time(NULL);
+if ((int)(now - lb_priv-error_time) lb_priv-timeout) {
+#ifdef HAS_APR
+apr_thread_yield();
+#endif
+continue;
+}
+}
+else
+lb_priv-error_time = time(NULL);
}
else if (!rec){
/* If we are initializing the service wait until
@@ -340,7 +357,7 @@
if (lb-cs != NULL) {
lb-cs-lock(env, lb-cs);
lb-cs-unLock(env, lb-cs);
-}
+}
continue;
}
attempt++;
@@ -370,6 +387,7 @@
}
s-afterRequest( env, s);
+lb_priv-error_time = time(NULL);
return JK_ERR;
}
@@ -502,6 +520,7 @@
jk_worker_t *lb=mbean-object;
char *value=valueP;
unsigned i = 0;
+jk_worker_lb_private_t *lb_priv = lb-worker_private;
if( strcmp( name, worker) == 0 ) {
if( lb-lbWorkerMap-get( env, lb-lbWorkerMap, name) != NULL ) {
@@ -523,7 +542,13 @@
lb-noWorkerCode=atoi( value );
} else if( strcmp( name, hwBalanceErr) == 0 ) {
lb-hwBalanceErr=atoi( value );
-}
+} else if( strcmp( name, timeout) == 0 ) {
+lb_priv-timeout=atoi( value );
+} else if( strcmp( name, recovery) == 0 ) {
+lb_priv-recovery=atoi( value );
+} else if( strcmp( name, attempts) == 0 ) {
+lb_priv-attempts=atoi( value );
+}
return JK_ERR;
}
@@ -594,7 +619,9 @@
if( jkb != NULL ) {
worker_private-cs=jkb-object;
jkb-init(env, jkb );
-}
+
Re: Tomcat 4.1.12 and Servlet Access 404 Errors: BUG? One Last Assurance
On Wed, 2 Oct 2002, micael wrote: Date: Wed, 02 Oct 2002 00:12:20 -0700 From: micael [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: Tomcat 4.1.12 and Servlet Access 404 Errors: BUG? One Last Assurance So I can understand, where is the difference in the code between Tomcat 4.1.10 and 4.1.12? And, do you mean that servlet mappings rather than being generic to some servlet/* path be individualized? Let's assume that you have two servlets that are currently accessed via the following URLs: http://localhost:8080/myapp/servlet/com.mypackage.MyFooServlet http://localhost:8080/myapp/servlet/com.mypackage.MyBarServlet that no longer work in 4.1.12. To avoid changing all your URLs, you have two basic choices: (1) Re-enable the invoker servlet by uncommenting the /servlet/* mapping in $CATALINA_HOME/conf/web.xml (non-portable, might be open to future vulnerabilities) (2) Explicitly add servlet definitions and mappings for these two servlets: web-app servlet servlet-nameFoo/servlet-name servlet-classcom.mypackage.MyFooServlet/servlet-class /servlet servlet servlet-nameBar/servlet-name servlet-classcom.mypackage.MyBarServlet/servlet-class /servlet servlet-mapping servlet-nameFoo/servlet-name url-pattern/servlet/com.mypackage.MyFooServlet/url-pattern /servlet-mapping servlet-mapping servlet-nameBar/servlet-name url-pattern/servlet/com.mypackage.MyBarServlet/url-pattern /servlet-mapping /web-app The latter choice will selectively re-enable only the servlet mappings that you actually need. This is also guaranteed to be portable across servlet containers, whereas the invoker servlet is just a Tomcat feature. Craig At 12:26 PM 10/2/2002 +1000, you wrote: micael wrote: I cannot access a webapp with the normal http://localhost:8080/myapp/servlet/mydirectory.MyServlet with Tomcat 4.1.12. (Also, the embedded Tomcat 4.1.12 in JBoss 3.0.3 runs fine except that it won't access the examples servlets.) The error shown is a 404 The requested resource (/myapp/servlet/mydirectory.MyServlet) is not available.. The same thing runs fine with Tomcat 4.1.0., both with and without JBoss. Is this a BUG in Tomcat 4.1.12, or are there new constraints on reaching servlets from outside the container in 4.1.12? For security reasons (see the release notes for details), the invoker servlet is disabled by default now. This servlet is what makes /webapp/servlet/... paths invoke the given servlet. It's recommended that you give explicit servlet definitions and mappings in the webapps's web.xml instead. Michael -- 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: [Possible bug with jspc]
Here is a bit more information. I took a look at the jar files for jsp 1.1 tags and they include a taglib.tld file in meta-inf/. Once I remove that, it compiles the pages fine. It looks like there's a conflict in either jasper compiler or jspc that is unable to resolve which .tld file to use. peter lin wrote: I spent the last two days trying to use JspC to compile an entire webapp and came across a problem. I'm not sure if this is a bug or not, but I can reproduce it every time. I'm still trying to track down the cause, but I thought I'd post a question and maybe some one with more knowledge can point me in the right direction. I am using the following command to run jspc C:\tomcat\binjspc -d ..\work\Standalone\localhost\_ -uribase c:/myapp/web -webapp c:/myapp/web in one of included files I define all the taglibs i use. right now I am using taglibs from the Jakarta. If I use the string tag, it causes JspC to die with NPE. If I remove the %@ taglib % for string tag, jspc works fine. the main difference between JSTL and string tag is JSTL is 1.2 and string tag is 1.1. the page works just fine if I load it in the browser, but for some reason, JspC doesn't like 1.1 taglibs. can anyone provide any insight? peter lin -- 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]
FW: Software caused connection abort
This might be the right place for this post? -Original Message- From: Jindong Li Sent: Wednesday, October 02, 2002 10:15 AM To: '[EMAIL PROTECTED]' Subject:Software caused connection abort Hi there, I'm trying out tomcat4.1.12 and noticed that I'm getting exception rather frequently when loading pages, although it doesn't appear to affect the way webserver works - the pages still load properly ... Environment: Windows 2000, Tomcat 4.1.12 standalone, JDK 1.4.0 . Here's the exception: 2002-10-02 10:11:40 StandardWrapperValve[default]: Servlet.service() for servlet default threw exception java.net.SocketException: Software caused connection abort: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:126) at org.apache.coyote.http11.InternalOutputBuffer$OutputStreamOutputBuffer.doWri te(InternalOutputBuffer.java:652) at org.apache.coyote.http11.filters.IdentityOutputFilter.doWrite(IdentityOutput Filter.java:160) at org.apache.coyote.http11.InternalOutputBuffer.doWrite(InternalOutputBuffer.j ava:523) at org.apache.coyote.Response.doWrite(Response.java:513) at org.apache.coyote.tomcat4.OutputBuffer.realWriteBytes(OutputBuffer.java:380) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:360) at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:338) at org.apache.coyote.tomcat4.OutputBuffer.writeBytes(OutputBuffer.java:407) at org.apache.coyote.tomcat4.OutputBuffer.write(OutputBuffer.java:394) at org.apache.coyote.tomcat4.CoyoteOutputStream.write(CoyoteOutputStream.java:1 10) at org.apache.catalina.servlets.DefaultServlet.copyRange(DefaultServlet.java:19 96) at org.apache.catalina.servlets.DefaultServlet.copy(DefaultServlet.java:1745) at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.jav a:1073) at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:506) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilter Chain.java:98) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain .java:176) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:172) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2396) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180 ) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve. java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172 ) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at
Problem with Tomcat 4
Hi, I am getting the following exception off the JSP engine in my tomcat 4.0 when I try to execute a class file off my linux box. The details are as given below. java.lang.NoClassDefFoundError: sun/io/MalformedInputException at sun.tools.java.Scanner.init(Scanner.java:144) at sun.tools.java.Parser.init(Parser.java:52) at sun.tools.javac.BatchParser.init(BatchParser.java:54) at sun.tools.javac.BatchEnvironment.parseFile(BatchEnvironment.java:453) at sun.tools.javac.Main.compile(Main.java:486) at org.apache.jasper.compiler.SunJavaCompiler.compile(SunJavaCompiler.java:158) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:273) at org.apache.jasper.servlet.JspServlet.doLoadJSP(JspServlet.java:612) at org.apache.jasper.servlet.JasperLoader12$1.run(JasperLoader12.java:160) at java.security.AccessController.doPrivileged(AccessController.java:37) at org.apache.jasper.servlet.JasperLoader12.loadJSP(JasperLoader12.java:156) at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:542) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNecessary(JspServlet.java:258) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:268) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:429) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:500) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405) at org.apache.tomcat.core.Handler.service(Handler.java:287) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:806) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:752) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:213) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) at java.lang.Thread.run(Thread.java:325)Warning: Major version number mismatch.Warning: Minor version number mismatch.2002-10-02 17:25:59 - Ctx( /gap ): JasperException: R( /gap + /Holidays.jsp + null) Unable to compile class for JSPNote: sun.tools.javac.Main has been deprecated.error: An error has occurred in the compiler; please file a bug report (http://java.sun.com/cgi-bin/bugreport.cgi).1 error, 1 warning Please Help.. Regards Shravan Sadasivan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
isapi_redirect.dll file
Hello, Can you email me this file isapi_redirect.dll , as i couldn't find it. Thank You. Regards, Ashley
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
-Original Message- From: [EMAIL PROTECTED] Modified:jk/native2/common jk_worker_lb.c Log: Introduced 3 new configuration parameters to the lb. 1. attempts -- replaces harcoded MAX_ATTEMPTS 2. recovery -- replaces hardcoded WAIT_BEFORE_RECOVER 3. timeout -- this one is new. The timeout if set will force the lb to cycle through workers if all are in the error_state for the specified amount of seconds. This is usefull for situations when the TC is overloaded and refuses new connections. The lb will wait and after timeout will report 500 to the client. Some more clarification: The reason for introducing timeout inside lb is from my point of view and the applications I'm using jk2 for, fact that even using most powerful system, there will be situations that returns 500 to the client simply because the TC is to busy and refuses new connections. One way to solve that is to force the TC to allow more connections eating system resources, and the other is using lb timeout. One drawback of using timeout is the fact that the client will get delayed response even for the non-existent configured TC instance. I've made such behavior at first inside the socket connector, but Nacho (he was right) made a strong objection to that. So instead trying to connect to the instance from connector point of view, all that is put inside the load balancer. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
De: Mladen Turk [mailto:[EMAIL PROTECTED]] Enviado el: 2 de octubre de 2002 17:50 I there any way to disable completely that timeout? Perhaps setting it to -1 or something like that? This timeout disabled should be the default config.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
It is disabled by default and never checked (if you don't set the timeout=x inside the [lb]). I there any way to disable completely that timeout? Perhaps setting it to -1 or something like that? This timeout disabled should be the default config.. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tagging JK2_2_0_1?
There has been some major fixes inside the uriMap, uriEnv, apr_socket and lb that makes the 2_0_0 IMO unusable, and personally I'm ashamed as a RM that this was a release after all :(. Since we tagged and released JK2 as beta, seems to me that we could easily do the same for the 2.0.1, and just pretend that 2.0.0 ewer existed :) The question is are we going to wait for a Apache1.3/APR/JNI builds or just go without that. But before going to the 2_0_1 (What doesn't kill you makes you stronger ;) could you guys do the testing against current CVS for all the discussed items. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13212] New: - JSPC is unable to compile when JSP1.1 taglib jar contains tld file
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=13212. 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=13212 JSPC is unable to compile when JSP1.1 taglib jar contains tld file Summary: JSPC is unable to compile when JSP1.1 taglib jar contains tld file Product: Tomcat 4 Version: 4.1.12 Platform: All OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I can reproduce this every consistently. The bug appears when JSP 1.1 tag jar file contains meta-inf/*.tld file. instructions for reproducing the bug. 1. create a simple page that uses jakarta string taglib 2. run jspc Result: NPE should be thrown and page should not compile. work around. 1. delete the .tld file from string.jar 2. run jspc It would appear there's a conflict between the .tld file under myWebApp/WEB-INF/string.tld and meta-inf/taglib.tld in the jar. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11657] - AJP13 Connector redirect does not work
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=11657. 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=11657 AJP13 Connector redirect does not work [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||REMIND --- Additional Comments From [EMAIL PROTECTED] 2002-10-02 16:01 --- I assume you are talking about a HTTPS site and a redirect. One problem is that we can't be sure that sun's jars are used. Some people use Apache+SSL and tomcat without SSL. We need to find a better solution for that. Can you send a stack trace ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Patch] Make mod_jk2 send REDIRECT_* headers for ErrorDocument usage
Hi, The attached patch for mod_jk2 (apache 1.3 and apache 2.0) sends a REDIRECT_URL and a REDIRECT_QUERYSTRING header if the request inside apache is redirected (e.g. through the use of the ErrorDocument directive). This follows the environment variables detailed in http://httpd.apache.org/docs-2.0/custom-error.html. Currently if a jsp/servlet is used within an ErrorDocument directive it has no knowledge of the original request. Regards, Tom Tom Palmer Web Systems Developer WorldCom 332 Science Park, Cambridge, CB4 0BZ, UK Tel: +44 (0)1223 250246 jk2.errordocument.patch Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Strange problem with tomcat 4.1.2
Definitely a problem with an extra '--' in your XML comments. The only place that '--' is allowed is at the beginning and at the end: !--blah blah-- Han Ming On Wednesday, October 2, 2002, at 04:32 AM, Henri Gomez wrote: While working on 4.1.2 rpms I noticed the following error at startup : 4732 [main] INFO modeler.Registry - Creating MBeanServer 5705 [main] INFO http11.Http11Protocol - Initializing Coyote HTTP/1.1 on port 8080 Starting service Tomcat-Standalone Apache Tomcat/4.1 7324 [main] ERROR digester.Digester - Parse Fatal Error at line 307 column 39: The string -- is not permitted within comments. org.xml.sax.SAXParseException: The string -- is not permitted within comments. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unkn own Source) at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source) at org.apache.xerces.impl.XMLScanner.scanComment(Unknown Source) at org.apache.xerces.impl.XMLDTDScannerImpl.scanComment(Unknown Source) at org.apache.xerces.impl.XMLDTDScannerImpl.scanDecls(Unknown Source) at org.apache.xerces.impl.XMLDTDScannerImpl.scanDTDExternalSubset(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(Un known Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unkn own Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse(Digester.java:1514) at org.apache.catalina.startup.ContextConfig.tldScanStream(ContextConfig.j ava:977) at org.apache.catalina.startup.ContextConfig.tldScanTld(ContextConfig.java :1006) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:87 0) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig. java:243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleS upport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:349 3) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497 ) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2189) at org.apache.catalina.startup.Catalina.start(Catalina.java:510) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) 8720 [main] ERROR digester.Digester - Parse Fatal Error at line 307 column 39: The string -- is not permitted within comments. org.xml.sax.SAXParseException: The string -- is not permitted within comments. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unkn own Source) at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) Admin log show me the following error : 2002-10-02 13:29:01 WebappLoader[/admin]: Deploying class repositories to work directory /var/tomcat4/work/Standalone/localhost/admin 2002-10-02 13:29:01 WebappLoader[/admin]: Deploy class files /WEB-INF/classes to /var/tomcat4/webapps/../server/webapps/admin/WEB-INF/classes 2002-10-02 13:29:01 WebappLoader[/admin]: Deploy JAR /WEB-INF/lib/struts.jar to /var/tomcat4/webapps/../server/webapps/admin/WEB-INF/lib/struts.jar 2002-10-02 13:29:02 ContextConfig[/admin] Exception processing TLD at resource path /WEB-INF/controls.tld javax.servlet.ServletException: Exception processing TLD at resource path /WEB-INF/controls.tld at org.apache.catalina.startup.ContextConfig.tldScanTld(ContextConfig.java :1010) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:87 0) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.
RE: [VOTE] [5.0] Milestones
Not a vote, just wondered when we can expect to see the milestone builds appearing? Kevin Jones Developmentor www.develop.com -Original Message- From: Larry Isaacs [mailto:[EMAIL PROTECTED]] Sent: 30 September 2002 20:14 To: Tomcat Developers List Subject: RE: [VOTE] [5.0] Milestones -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Saturday, September 28, 2002 10:12 AM To: Tomcat Developers List Subject: [VOTE] [5.0] Milestones Hi, Now that the first stable releases of Tomcat 4.1 are out (and according to reports, of good overall quality), it could be appropriate to start releasing 5.0.x milestones. It should be pointed out that 5.0.x is still far from being feature complete (esp the configuration code needs to be unified if possible, and some optimizations are needed), so the milestones should be considered alpha or pre alpha until further notice. ballot [X] +1 Yes, start releasing milestones [ ] -1 No, because: /ballot Remy -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
Are we documenting all those settings - and the details on why/how :-) ? Mladen Turk wrote: It is disabled by default and never checked (if you don't set the timeout=x inside the [lb]). I there any way to disable completely that timeout? Perhaps setting it to -1 or something like that? This timeout disabled should be the default config.. -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Need some clarifications
On Wed, 2002-10-02 at 09:38, Christian Gross wrote: Hi So I worked myself through the various CVS sources and have a couple of official position questions to ask. The CVS projects jakarta-tomcat-catalina and jakarta-tomcat-jasper, will be forming the Tomcat 5 work? Yup. The CVS project jakarta-tomcat-4.0 is the 4.x branch? yes. I think the 4.0 is tagged in there, but the HEAD is 4.1 The CVS project jakarta-tomcat is anything before 4.0 yup. The CVS project jakarta-tomcat-5.0 does nothing?? It is jakarta-tomcat-5, not 5.0 and it is used to pull together the other bits to make Tomcat5. If you want to build TC5, just use the attached build.xml and type ant Cheers, -bob Thanks, for any help Christian Gross Software Engineering Consultant http://www.devspace.com North America: 1-450-675-4208 Europe +41.1.701.1166 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Bob Herrmann [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
-Original Message- On Behalf Of Costin Manolache Are we documenting all those settings - and the details on why/how :-) ? Sure, like everyone else ;). MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11657] - AJP13 Connector redirect does not work
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=11657. 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=11657 AJP13 Connector redirect does not work [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|REMIND | --- Additional Comments From [EMAIL PROTECTED] 2002-10-02 17:24 --- Actually, you're right - for jdk1.3+ it should work. I'll add code to initialize it for ajp ( if not already set ). Probably next release will have it. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tagging JK2_2_0_1?
De: Mladen Turk [mailto:[EMAIL PROTECTED]] Enviado el: 2 de octubre de 2002 18:11 Well, in theory, the release is only labeled as alpha,beta,stable,GA or whatever, after the tagging and the relase itself ( stagging in a test place not the official builds one ) , asking for a vote about the label should be for the release.. SO tag it, release it to test stagging area, and call for a vote some days later about wich sis the label the relase will have.. No doubt we will end having a buch 2.0.X relase, until everything is finished.. docs.. and so on.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
Mladen Turk wrote: -Original Message- On Behalf Of Costin Manolache Are we documenting all those settings - and the details on why/how :-) ? Sure, like everyone else ;). Yes, I know :-) I'll try to get over the horrible and nonstandard DTD that we use and start documenting what I can still remember, and anything new that I add. And I won't write any new jk code until I finish at least reviewing all the bugs ( 80 ? ) -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
-Original Message- Sure, like everyone else ;). Yes, I know :-) I'll try to get over the horrible and nonstandard DTD that we use and start documenting what I can still remember, and anything new that I add. And I won't write any new jk code until I finish at least reviewing all the bugs ( 80 ? ) Roger to that. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Need some clarifications
On Wednesday 02 October 2002 09:38 am, Christian Gross wrote: Hi So I worked myself through the various CVS sources and have a couple of official position questions to ask. The CVS projects jakarta-tomcat-catalina and jakarta-tomcat-jasper, will be forming the Tomcat 5 work? jakarta-servletapi-5, jakarta-tomcat-5, jakarta-tomcat-catalina, jakarta-tomcat-connectors, jakarta-tomcat-jasper, and jakarta-watchdog-4.0 are the CVS repositories involved in Tomcat 5.0 The CVS project jakarta-tomcat-4.0 is the 4.x branch? Yes The CVS project jakarta-tomcat is anything before 4.0 Tomcat 3.x, at least. The CVS project jakarta-tomcat-5.0 does nothing?? It's the master project for the whole Tomcat 5.0 project. To use it, start with a directory like tc5-workspace. In that directory: export CVSROOT=:pserver:[EMAIL PROTECTED]:/home/cvspublic cvs co jakarta-servletapi-5 cvs co jakarta-tomcat-5 cvs co jakarta-tomcat-catalina cvs co jakarta-tomcat-connectors cvs co jakarta-tomcat-jasper then, in jakarta-tomcat-5 create a build.properties file with the following definition base.path = /home/sdowney/tc5-workspace/depends (replace /home/sdowney/tc5-workspace with path to your workspace. I don't know if relative will work. I stopped dinking when I got my build system to function) You need ant 1.5 to build Tomcat 5 export ANT_HOME=/home/sdowney/tools/jakarta-ant-1.5 PATH=$PATH:$ANT_HOME/bin ant download The download target in Tomcat 5 gets the necessary ancillary libraries to build the system. I'm using JDK 1.4, which has a few things built in. You may need to install some things in JDK 1.3, like JCE. I'm not sure. Then: ant build ant test [Not many tests at the moment] If you're contributing, you may also want to do ant -Dfull.dist=on build That will force a full compile, rather than checking which optional components are available and setting things on or off based on the presense or absense of classes. That useful for building a customized version, but for testing purposes, a full build is better. To run the watchdog conformance test suite: ant watchdog -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 471] - Problem using jk_nt_service (with a blank space in tomcat_home directory path) BugRat Report#797
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=471. 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=471 Problem using jk_nt_service (with a blank space in tomcat_home directory path) BugRat Report#797 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2002-10-02 18:37 --- This has been fixed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
3798: service monitor for jk_nt_service
Can someone with windows experience check the attachment and decide what to do ? It seems like usefull and good, but I don't know what is the benefit over just using 'net start' or the default service manager. -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5877] - Facade of facade.
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=5877. 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=5877 Facade of facade. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-02 18:57 --- That doesn't seem like a connector problem. AFAIK the facade is needed for security ( to prevent code holding references when recycling ). I never seen 2 facades and user code shouldn't get access to the real object in any case ! If it can - that's a serious security issue, please reopen the bug ( in the right category ) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4371] - No responses on browsing root when using WarpConnector
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=4371. 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=4371 No responses on browsing root when using WarpConnector [EMAIL PROTECTED] changed: What|Removed |Added Component|Connector:Other |Connector:Webapp -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [patch] JNDIRealm and SSL
Fredrik Westermarck wrote: Hi! I have added the possibility to use SSL with the JNDIRealm in the file JNDIRealm.java.diff. So how about this patch? Anyone that want to commit it, or else comment on how it could be done in a better way? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12946] - parameter serverRoot from jk2.properties not read; workaround
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=12946. 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=12946 parameter serverRoot from jk2.properties not read; workaround --- Additional Comments From [EMAIL PROTECTED] 2002-10-02 20:15 --- I'm confused: the output is from the native side jk, which is configured using workers2.properties. Are you using in-process jk ? Can you give more info about the env and a full log file ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9936] - http tunnel could not work with 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=9936. 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=9936 http tunnel could not work with mod_jk --- Additional Comments From [EMAIL PROTECTED] 2002-10-02 20:24 --- Can you reproduce this without using a plugin ( ie. a small java client or use ant tasks to upload/send data ) ?? Most likely it's an issue with the body ( does it have Content-Length ?). You can enable debugging in several places in jk - to see what is sent. ( or use etherreal ! ) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8107] - uninstall mod_jk2-2.0 rpm not possible
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=8107. 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=8107 uninstall mod_jk2-2.0 rpm not possible [EMAIL PROTECTED] changed: What|Removed |Added Component|Connector:Coyote JK 2 |Installable Packages --- Additional Comments From [EMAIL PROTECTED] 2002-10-02 20:27 --- Henri ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12750] - Virtual hosts using Apache 2.0.40, Tomcat 4.1.10 and mod_jk2
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=12750. 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=12750 Virtual hosts using Apache 2.0.40, Tomcat 4.1.10 and mod_jk2 --- Additional Comments From [EMAIL PROTECTED] 2002-10-02 20:30 --- Can you attach the config files used ( workers2.properties, server.xml ) ? Also - check the log/ directory for messages - it should have something... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13221] New: - JDBC DataSource driverClassName is required 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=13221. 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=13221 JDBC DataSource driverClassName is required error Summary: JDBC DataSource driverClassName is required error Product: Tomcat 4 Version: 4.0.1 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm getting the following error when I try and obtain a DataSource reference via the Initial Context: javax.naming.NamingException: DbcpDataSourceFactory: driverClassName is required at org.apache.naming.factory.DbcpDataSourceFactory.getObjectInstance (Unknown Source) at org.apache.naming.factory.ResourceFactory.getObjectInstance (Unknown Source) at javax.naming.spi.NamingManager.getObjectInstance (NamingManager.java:299) at org.apache.naming.NamingContext.lookup(Unknown Source) at org.apache.naming.NamingContext.lookup(Unknown Source) at org.apache.naming.NamingContext.lookup(Unknown Source) at org.apache.naming.NamingContext.lookup(Unknown Source) at org.apache.naming.NamingContext.lookup(Unknown Source) at org.apache.naming.NamingContext.lookup(Unknown Source) at org.apache.naming.NamingContext.lookup(Unknown Source) at org.apache.naming.NamingContext.lookup(Unknown Source) at org.apache.naming.SelectorContext.lookup(Unknown Source) at javax.naming.InitialContext.lookup(InitialContext.java:345) at tutorial.HelloServlet.service(HelloServlet.java:53) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Unknown Source) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown Source) at org.apache.catalina.core.StandardWrapperValve.invoke(Unknown Source) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(Unknown Source) at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source) at org.apache.catalina.core.ContainerBase.invoke(Unknown Source) at org.apache.catalina.core.StandardContextValve.invoke(Unknown Source) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(Unknown Source) at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source) at org.apache.catalina.core.ContainerBase.invoke(Unknown Source) at org.apache.catalina.core.StandardContext.invoke(Unknown Source) at org.apache.catalina.core.StandardHostValve.invoke(Unknown Source) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(Unknown Source) at org.apache.catalina.valves.ErrorDispatcherValve.invoke (Unknown Source) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(Unknown Source) at org.apache.catalina.valves.ErrorReportValve.invoke(Unknown Source) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(Unknown Source) at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source) at org.apache.catalina.core.ContainerBase.invoke(Unknown Source) at org.apache.catalina.core.StandardEngineValve.invoke(Unknown Source) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(Unknown Source) at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source) at org.apache.catalina.core.ContainerBase.invoke(Unknown Source) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:405) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnectio n(Http11Protocol.java:358) at org.apache.tomcat.util.net.TcpWorkerThread.runIt (PoolTcpEndpoint.java:495) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:518) at java.lang.Thread.run(Thread.java:479) The datasource appears to register correctly when the server starts: DbcpDataSourceFactory: driverClassName=com.merant.datadirect.jdbc.sqlserver.SQL ServerDriver, url=jdbc:merant:sqlserver:tbftradesdb@mydb:1433, user=dbo Here is the server.xml snippet: Resource name=jdbc/FillDataSource auth=Container type=javax.sql.DataSource / - ResourceParams name=jdbc/FillDataSource parameter nameuser/name valuedbo/value /parameter parameter namepassword/name valueduff/value /parameter parameter
Little refactoring in o.a.t.u.net
I have in my workspace working a litle refactoring of the o.a.t.u.net package translating the JSSE* classes to his own package ( named of course jsse) and the same for PureTLs* ones ( with a package name of ptls), i have the tc4.1.X tc5 versions working, and i can put the tc33 and others working too, althought I only need this to be able to use RefactorIt.. :)) ( the real reason is that the only way to make RefactorIt to exclude some package is for complete packages not single files ) I know this is very sensitive code used by many other packages parts, i can live with the change in my workspace without problems.,. but maybe this is useful for anyone more.. Comments? Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Little refactoring in o.a.t.u.net
Tar the code and post it here...so we can look and enjoy :-) -- Jeanfrancois Ignacio J. Ortega wrote: I have in my workspace working a litle refactoring of the o.a.t.u.net package translating the JSSE* classes to his own package ( named of course jsse) and the same for PureTLs* ones ( with a package name of ptls), i have the tc4.1.X tc5 versions working, and i can put the tc33 and others working too, althought I only need this to be able to use RefactorIt.. :)) ( the real reason is that the only way to make RefactorIt to exclude some package is for complete packages not single files ) I know this is very sensitive code used by many other packages parts, i can live with the change in my workspace without problems.,. but maybe this is useful for anyone more.. Comments? Saludos , Ignacio J. Ortega -- 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: Little refactoring in o.a.t.u.net
- Original Message - From: Ignacio J. Ortega [EMAIL PROTECTED] To: 'tomcat-dev' [EMAIL PROTECTED] Sent: Wednesday, October 02, 2002 1:51 PM Subject: Little refactoring in o.a.t.u.net I have in my workspace working a litle refactoring of the o.a.t.u.net package translating the JSSE* classes to his own package ( named of course jsse) and the same for PureTLs* ones ( with a package name of ptls), i have the tc4.1.X tc5 versions working, and i can put the tc33 and others working too, althought I only need this to be able to use RefactorIt.. :)) ( the real reason is that the only way to make RefactorIt to exclude some package is for complete packages not single files ) I know this is very sensitive code used by many other packages parts, i can live with the change in my workspace without problems.,. but maybe this is useful for anyone more.. Comments? +1 It's a little messy in o.a.t.u.net. Nobody should be be accessing the JSSE* PureTLS* classes directly, so moving them shouldn't cause any problems (and if it does, then it's a bug ;). Just remember to change the class names in SSLImplementation. Saludos , Ignacio J. Ortega -- 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: Little refactoring in o.a.t.u.net
here it is, only the net package zipped.. one point to look at, I've converted the CipherData class in a inner one with public data.. all other is merely renaming packages and moving files.. Saludos , Ignacio J. Ortega -Mensaje original- De: Jean-Francois Arcand [mailto:[EMAIL PROTECTED]] Enviado el: 2 de octubre de 2002 22:57 Para: Tomcat Developers List Asunto: Re: Little refactoring in o.a.t.u.net Tar the code and post it here...so we can look and enjoy :-) -- Jeanfrancois Ignacio J. Ortega wrote: I have in my workspace working a litle refactoring of the o.a.t.u.net package translating the JSSE* classes to his own package ( named of course jsse) and the same for PureTLs* ones ( with a package name of ptls), i have the tc4.1.X tc5 versions working, and i can put the tc33 and others working too, althought I only need this to be able to use RefactorIt.. :)) ( the real reason is that the only way to make RefactorIt to exclude some package is for complete packages not single files ) I know this is very sensitive code used by many other packages parts, i can live with the change in my workspace without problems.,. but maybe this is useful for anyone more.. Comments? Saludos , Ignacio J. Ortega -- 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] Net.zip Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13223] New: - JSP pages in XML syntax do not compile properly
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=13223. 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=13223 JSP pages in XML syntax do not compile properly Summary: JSP pages in XML syntax do not compile properly Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When using the XML syntax for JSP pages, compile errors are thrown whenever an XML-syntax JSP tag is used to apply an attribute value as in this JSP page: This JSP fails: jsp:root xmlns:jsp=http://java.sun.com/JSP/Page; version=1.2 jsp:directive.page language=java import=java.text.* session=false isThreadSafe=true isErrorPage=false / jsp:scriptlet java.text.Annotation recordDetails = new java.text.Annotation(This is a test value); pageContext.setAttribute(recordDetails, recordDetails, PageContext.PAGE_SCOPE); /jsp:scriptlet html head titlejsp:expressionSystem.getProperty(java.io.tmpdir) /jsp:expression/title /head body table class=EntryFormContainer cols=6 cellpadding=1 cellspacing=1 border=0 tr td align=rightCase ID:/td td align=left colspan=7input type=text name=caseID READONLY=true value='jsp:getProperty name=recordDetails property=value /' class=DisabledField//td /tr /table /body /html /jsp:root This JSP works: jsp:root xmlns:jsp=http://java.sun.com/JSP/Page; version=1.2 jsp:directive.page language=java import=java.text.* session=false isThreadSafe=true isErrorPage=false / jsp:scriptlet java.text.Annotation recordDetails = new java.text.Annotation(This is a test value); pageContext.setAttribute(recordDetails, recordDetails, PageContext.PAGE_SCOPE); /jsp:scriptlet html head titlejsp:expressionSystem.getProperty(java.io.tmpdir) /jsp:expression/title /head body table class=EntryFormContainer cols=6 cellpadding=1 cellspacing=1 border=0 tr td align=rightCase ID:/td td align=left colspan=7input type=text name=caseID READONLY=true value= class=DisabledField/jsp:getProperty name=recordDetails property=value //td /tr /table /body /html /jsp:root This JSP also fails: jsp:root xmlns:jsp=http://java.sun.com/JSP/Page; version=1.2 jsp:directive.page language=java import=java.text.* session=false isThreadSafe=true isErrorPage=false / jsp:scriptlet java.text.Annotation recordDetails = new java.text.Annotation(This is a test value); pageContext.setAttribute(recordDetails, recordDetails, PageContext.PAGE_SCOPE); /jsp:scriptlet html head titlejsp:expressionSystem.getProperty(java.io.tmpdir) /jsp:expression/title /head body table class=EntryFormContainer cols=6 cellpadding=1 cellspacing=1 border=0 tr td align=rightCase ID:/td td align=left colspan=7input type=text name=caseID READONLY=true value='jsp:getProperty name=recordDetails property=value' class=DisabledField//td /tr /table /body /html /jsp:root Several additional variations on the above themes also fail. The spec appears to support the first JSP example. On the chance that I might have misread the spec, I also tried it without the and /, this variation also fails. It may be worth noting that this exact same example JSP works, as long as the jsp:root tag is removed and the page, scriptlet, and expression tags are replaced with their non-XML equivalents as follows: %@page language=java import=java.text.* session=false isThreadSafe=true isErrorPage=false % % java.text.Annotation recordDetails = new java.text.Annotation(This is a test value); pageContext.setAttribute(recordDetails, recordDetails, PageContext.PAGE_SCOPE); % html head title%=System.getProperty(java.io.tmpdir)%/title /head body table class=EntryFormContainer cols=6 cellpadding=1 cellspacing=1 border=0 tr td align=rightCase ID:/td td align=left colspan=7input type=text name=caseID READONLY=true value='jsp:getProperty name=recordDetails property=value /' class=DisabledField//td /tr /table /body /html In summary, it appears that the XML syntax is not supported in attribute value assignment. The exception thrown is as follows (Note the problem in property lookup, this may be another, unrelated, bug). type
DO NOT REPLY [Bug 13226] New: - Can't access files with international characters
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=13226. 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=13226 Can't access files with international characters Summary: Can't access files with international characters Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Using Tomcat 4.0.4 (installed from the RPMs now in the Jakarta archives), if Tomcat is serving a file that has international characters in the filename and a user requests that file, Tomcat misinterprets the filename. As a result, it gives an error, The requested resource is not available. For example, accessing http://localhost/Björk; yields the error, The requested resource (/Björk/) is not available. The expected result is to process the international characters in the filename correctly, and serve the file. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Is Compile Failure? was Re: Need some clarifications
Thanks for your answer. That helps quite a bit. Now I have another issue... build-catalina: [javac] Compiling 94 source files to D:\Instructor\Projects\jakarta-tomcat-c atalina\build\server\classes [javac] D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or g\apache\catalina\startup\ContextConfig.java:537: cannot resolve symbol [javac] symbol : method setEntityResolver (org.apache.catalina.util.Schema Resolver) [javac] location: class org.apache.commons.digester.Digester [javac] tldDigester.setEntityResolver(tldEntityResolver); [javac]^ [javac] D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or g\apache\catalina\startup\ContextConfig.java:595: cannot resolve symbol [javac] symbol : method setEntityResolver (org.apache.catalina.util.Schema Resolver) [javac] location: class org.apache.commons.digester.Digester [javac] webDigester.setEntityResolver(webEntityResolver); [javac]^ [javac] D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or g\apache\catalina\util\SchemaResolver.java:154: cannot resolve symbol [javac] symbol : method setPublicId (java.lang.String) [javac] location: class org.apache.commons.digester.Digester [javac] digester.setPublicId(publicId); [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [javac] 3 errors BUILD FAILED file:D:/Instructor/Projects/jakarta-tomcat-catalina/catalina/build.xml:801: Comp ile failed; see the compiler error output for details. I checked out digester 1.3 and 1.2 and there does not seem to be a method setEntityResolver. Or am I missing something? Christian Gross At 14:18 02/10/2002 -0400, you wrote: On Wednesday 02 October 2002 09:38 am, Christian Gross wrote: Hi So I worked myself through the various CVS sources and have a couple of official position questions to ask. The CVS projects jakarta-tomcat-catalina and jakarta-tomcat-jasper, will be forming the Tomcat 5 work? jakarta-servletapi-5, jakarta-tomcat-5, jakarta-tomcat-catalina, jakarta-tomcat-connectors, jakarta-tomcat-jasper, and jakarta-watchdog-4.0 are the CVS repositories involved in Tomcat 5.0 The CVS project jakarta-tomcat-4.0 is the 4.x branch? Yes The CVS project jakarta-tomcat is anything before 4.0 Tomcat 3.x, at least. The CVS project jakarta-tomcat-5.0 does nothing?? It's the master project for the whole Tomcat 5.0 project. To use it, start with a directory like tc5-workspace. In that directory: export CVSROOT=:pserver:[EMAIL PROTECTED]:/home/cvspublic cvs co jakarta-servletapi-5 cvs co jakarta-tomcat-5 cvs co jakarta-tomcat-catalina cvs co jakarta-tomcat-connectors cvs co jakarta-tomcat-jasper then, in jakarta-tomcat-5 create a build.properties file with the following definition base.path = /home/sdowney/tc5-workspace/depends (replace /home/sdowney/tc5-workspace with path to your workspace. I don't know if relative will work. I stopped dinking when I got my build system to function) You need ant 1.5 to build Tomcat 5 export ANT_HOME=/home/sdowney/tools/jakarta-ant-1.5 PATH=$PATH:$ANT_HOME/bin ant download The download target in Tomcat 5 gets the necessary ancillary libraries to build the system. I'm using JDK 1.4, which has a few things built in. You may need to install some things in JDK 1.3, like JCE. I'm not sure. Then: ant build ant test [Not many tests at the moment] If you're contributing, you may also want to do ant -Dfull.dist=on build That will force a full compile, rather than checking which optional components are available and setting things on or off based on the presense or absense of classes. That useful for building a customized version, but for testing purposes, a full build is better. To run the watchdog conformance test suite: ant watchdog -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Christian Gross Software Engineering Consultant http://www.devspace.com North America: 1-450-675-4208 Europe +41.1.701.1166 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13060] - org.apache.jasper.JasperException: Unable to compile class for JSP
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=13060. 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=13060 org.apache.jasper.JasperException: Unable to compile class for JSP [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Component|Catalina|Jasper 2 OS/Version|Windows XP |Windows NT/2K Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 00:14 --- I experiance the same exception on Win NT 4. The reason why may be running Tomcat as a Windows Service using tomcat.exe. When I start Tomcat using startup.bat everything is fine, but when running the service the exception is thrown. Perhaps this may also help: I'm also using my own PreferencesFactory in conjunction with Log4J and therefore I have to add a jar file with all the required classes plus the log4j- 1.2.6.jar and jdom.jar to the classpath... HTH -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Weird seg fault on Mac OS X for mod_jk2 + Apache2
Folks, I'm trying to trace down a TCP_NODELAY problem and wanted to see if it exists on the latest connector mod_jk2. So I configured Apache 2.0.42, Tomcat 4.1.12 and downloaded jakarta-tomcat-connectors-4.1.12-src. I managed to use GNU's libtoolize to configure (./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-apr-lib=/usr/local/apache2/lib --with-apr-include=/usr/local/apache2/include --with-tomcat1=/usr/local/jakarta-tomcat-4.1.12). The compilation was successful and I copied mod_jk2.so to /usr/local/apache2/modules. I configured httpd.conf to load the module and appended the following: IfModule mod_jk2.c JkSet config.file /usr/local/apache2/conf/workers2.properties /IfModule I added a super simple workers2.properties file in the same dir and tried to start apache. I got a seg fault. Here's the stacktrace from Mac OS X default crash logger: Command:httpd PID:853 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x736f0028 Thread 0 Crashed: #0 0x90001600 in strlen #1 0x900023e0 in vfprintf #2 0x90015ee0 in __sbprintf #3 0x900018a8 in vfprintf #4 0x900017ec in fprintf #5 0x0060fdbc in jk2_map_default_get (jk_map.c:97) -- it's '97' because I added printf #6 0x0060df50 in jk2_env_createBean2 (jk_env.c:218) #7 0x0061ee0c in jk2_create_config (mod_jk2.c:351) #8 0x0002214c in ap_single_module_configure (config.c:1845) #9 0x7ad8 in load_module (mod_so.c:337) #10 0x00020308 in invoke_cmd (config.c:749) #11 0x000213d0 in execute_now (config.c:1347) #12 0x00020a40 in ap_build_config_sub (config.c:944) #13 0x00020f68 in ap_build_config (config.c:1151) #14 0x000218f0 in ap_process_resource_config (config.c:1556) #15 0x000220e8 in ap_read_config (config.c:1834) #16 0xc184 in main (main.c:615) #17 0x1ae0 in _start (crt.c:267) #18 0x1960 in start Here's output with some printf statements inserted in jk_map.c: entering for threadMutex (no. maps: 25) 0: logger.file (°Z°Z°Z°Z°Z°Z) - funny output is from fprintf(stderr,%s, mPriv-values[i]) 1: logger.win32 (°Z°Z°Z°Z°Z) 2: workerEnv (°Z°ZA°Z°Z) 3: uriMap (°Z°Za°Z°Z) 4: uriEnv (°Z°ZA°Z°Z) 5: endpoint (°Z°ZA°Z°Z) 6: uri (°Z°ZA°Z°Z) 7: config (°Z°Z°Z°Z°Z°Z) 8: ajp13 (°Z°ZA°Z°Z) 9: lb (,) 10: status (°Z°Z°Z°Z°Z) 11: run (,) 12: channel.un (°Z°ZA°Z°Z) 13: channel.apr (°Z°ZA°Z°Z) 14: shm (°Z°Z°Z°Z°Z°Z) 15: channel.socket (°Z°ZA°Z°Z) 16: handler.response (°Z°Z°Z°Z°Z°Z) 17: handler.logon (°Z°Z°Z°Z°Z°Z) 18: threadMutex (°Z°Z°Z°Z°Z°Z) done for threadMutex entering for logger.apache2: (no. maps: 1) 0: threadMutex:0 () done for logger.apache2: ... ... entering for uri:/examples/* (no. maps: 19) 0: threadMutex:0 () 1: logger.apache2: () 2: logger.apache2 () 3: logger () 4: uriMap: () 5: uriMap () 6: config: () 7: config () 8: shm: () 9: shm () 10: workerEnv: () 11: workerEnv () 12: uri: () 13: uri () 14: threadMutex:1 () 15: threadMutex:2 () 16: threadMutex:3 () 17: ajp13:localhost:8009 () 18: channel.socket:localhost:8009 () done for uri:/examples/* entering for uri (no. maps: 26) 0: logger.file (°Z°Z°Z°Z°Z°Z) 1: logger.win32 (°Z°Z°Z°Z°Z) 2: workerEnv (°Z°ZA°Z°Z) 3: uriMap (°Z°Za°Z°Z) 4: uriEnv (°Z°ZA°Z°Z) 5: endpoint (°Z°ZA°Z°Z) 6: uri (°Z°ZA°Z°Z) done for uri entering for workerEnv (no. maps: 19) 0: threadMutex:0 () 1: logger.apache2: () 2: logger.apache2 () 3: logger () 4: uriMap: () 5: uriMap () 6: config: () 7: config () 8: shm: () 9: shm () 10: workerEnv: () 11: workerEnv () done for workerEnv entering for ver (no. maps: 1) 0: worker (ajp13:localhost:8009) done for ver [here it churns for a few seconds before segfaulting] bin/apachectl: line 87: 853 Segmentation fault $HTTPD -k $ARGV Anyone has a clue on what could be wrong? Just pointers would help. I tried following the stack trace but am temporarily thrown off by how jk2_env_createBean2() gets to jk2_map_default_get(), especially the second parameter's type. It seems to be casted from (char *) to (jk_map_t *), which is kind of weird. Appreciate it. Han Ming # workers2.properties # Shared memory handling. Needs to be set. [shm] file=/usr/local/apache2/logs/shm.file size=1048576 # Example socket channel, explicitly set port and host. [channel.socket:localhost:8009]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_apr_socket.c jk_uriEnv.c jk_uriMap.c jk_worker_jni.c jk_worker_lb.c
nacho 2002/10/02 18:33:15
Modified:jk/native2/common jk_channel_apr_socket.c jk_uriEnv.c
jk_uriMap.c jk_worker_jni.c jk_worker_lb.c
Log:
Problems with EOL
I was unable to catch any of the multiple times this issue was discussed on the
list, but again..
Committing files with diferent EOL than the plataform we are working on,
damages them in CVS.. there are many ways to do this, but one of the
most commons is to have the sources in a linux i.e., edit them in win32
with an editor the completes the lf with a cr and commit then form linux..
I suppouse that are many combinations for that circunstance, take care..
Maybe old cygwin versions are problematic too , i dont know..
Revision ChangesPath
1.27 +32 -32
jakarta-tomcat-connectors/jk/native2/common/jk_channel_apr_socket.c
Index: jk_channel_apr_socket.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_apr_socket.c,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- jk_channel_apr_socket.c 2 Oct 2002 12:50:05 - 1.26
+++ jk_channel_apr_socket.c 3 Oct 2002 01:33:14 - 1.27
@@ -219,20 +219,20 @@
apr_socket_t *sock=endpoint-channelData;
apr_status_t ret;
apr_int32_t timeout = (apr_int32_t)(socketInfo-timeout * APR_USEC_PER_SEC);
-char msg[128];
+char msg[128];
int connected = 0;
-
+
while (remote_sa !connected) {
if ((ret = apr_socket_create(sock, remote_sa-family, SOCK_STREAM,
(apr_pool_t *)env-globalPool-_private))
!= APR_SUCCESS) {
env-l-jkLog(env, env-l, remote_sa-next ? JK_LOG_DEBUG :
JK_LOG_ERROR,
channelApr.open(): error %d creating socket %d %s\n,
- ret, socketInfo-host);
-remote_sa = remote_sa-next;
-continue;
-}
-
+ ret, socketInfo-host);
+remote_sa = remote_sa-next;
+continue;
+}
+
env-l-jkLog(env, env-l, JK_LOG_INFO,
channelApr.open(): create tcp socket %d\n, sock );
@@ -240,33 +240,33 @@
/* the default timeout (0) will set the socket to blocking with
infinite timeouts.
*/
-if (timeout = 0)
-apr_socket_timeout_set(sock, 0);
-else
+if (timeout = 0)
+apr_socket_timeout_set(sock, 0);
+else
apr_socket_timeout_set(sock, timeout);
-
-/* make the connection out of the socket */
-do {
-ret = apr_connect(sock, remote_sa);
-} while (APR_STATUS_IS_EINTR(ret));
-
-/* if an error occurred, loop round and try again */
-if (ret != APR_SUCCESS) {
-apr_socket_close(sock);
-env-l-jkLog(env, env-l, remote_sa-next ? JK_LOG_DEBUG :
JK_LOG_ERROR,
- channelApr.open() attempt to connect to %pI (%s) failed
%d\n,
- remote_sa,
- socketInfo-host,
- ret);
-remote_sa = remote_sa-next;
-continue;
-}
-connected = 1;
-}
-if (!connected) {
-apr_socket_close(sock);
-return JK_ERR;
+/* make the connection out of the socket */
+do {
+ret = apr_connect(sock, remote_sa);
+} while (APR_STATUS_IS_EINTR(ret));
+
+/* if an error occurred, loop round and try again */
+if (ret != APR_SUCCESS) {
+apr_socket_close(sock);
+env-l-jkLog(env, env-l, remote_sa-next ? JK_LOG_DEBUG :
JK_LOG_ERROR,
+ channelApr.open() attempt to connect to %pI (%s) failed
%d\n,
+ remote_sa,
+ socketInfo-host,
+ ret);
+remote_sa = remote_sa-next;
+continue;
+}
+connected = 1;
+}
+
+if (!connected) {
+apr_socket_close(sock);
+return JK_ERR;
}
/* enable the use of keep-alive packets on TCP connection */
if(keepalive) {
1.36 +11 -11jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c
Index: jk_uriEnv.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- jk_uriEnv.c 2 Oct 2002 10:27:17 - 1.35
+++ jk_uriEnv.c 3 Oct 2002 01:33:14 - 1.36
@@ -104,7
Re: Is Compile Failure? was Re: Need some clarifications
You need to be using the HEAD version of digester. It should have been built in the directory specified by base.path. Double check that it was built correctly. I just recreated it in my depends directory, and the system built fine. A number of the dependencies are unreleased at this point. 'ant download' tries to grab the correct ones. On Wednesday 02 October 2002 07:54 pm, Christian Gross wrote: Thanks for your answer. That helps quite a bit. Now I have another issue... build-catalina: [javac] Compiling 94 source files to D:\Instructor\Projects\jakarta-tomcat-c atalina\build\server\classes [javac] D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or g\apache\catalina\startup\ContextConfig.java:537: cannot resolve symbol [javac] symbol : method setEntityResolver (org.apache.catalina.util.Schema Resolver) [javac] location: class org.apache.commons.digester.Digester [javac] tldDigester.setEntityResolver(tldEntityResolver); [javac]^ [javac] D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or g\apache\catalina\startup\ContextConfig.java:595: cannot resolve symbol [javac] symbol : method setEntityResolver (org.apache.catalina.util.Schema Resolver) [javac] location: class org.apache.commons.digester.Digester [javac] webDigester.setEntityResolver(webEntityResolver); [javac]^ [javac] D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or g\apache\catalina\util\SchemaResolver.java:154: cannot resolve symbol [javac] symbol : method setPublicId (java.lang.String) [javac] location: class org.apache.commons.digester.Digester [javac] digester.setPublicId(publicId); [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [javac] 3 errors BUILD FAILED file:D:/Instructor/Projects/jakarta-tomcat-catalina/catalina/build.xml:801: Comp ile failed; see the compiler error output for details. I checked out digester 1.3 and 1.2 and there does not seem to be a method setEntityResolver. Or am I missing something? Christian Gross At 14:18 02/10/2002 -0400, you wrote: On Wednesday 02 October 2002 09:38 am, Christian Gross wrote: Hi So I worked myself through the various CVS sources and have a couple of official position questions to ask. The CVS projects jakarta-tomcat-catalina and jakarta-tomcat-jasper, will be forming the Tomcat 5 work? jakarta-servletapi-5, jakarta-tomcat-5, jakarta-tomcat-catalina, jakarta-tomcat-connectors, jakarta-tomcat-jasper, and jakarta-watchdog-4.0 are the CVS repositories involved in Tomcat 5.0 The CVS project jakarta-tomcat-4.0 is the 4.x branch? Yes The CVS project jakarta-tomcat is anything before 4.0 Tomcat 3.x, at least. The CVS project jakarta-tomcat-5.0 does nothing?? It's the master project for the whole Tomcat 5.0 project. To use it, start with a directory like tc5-workspace. In that directory: export CVSROOT=:pserver:[EMAIL PROTECTED]:/home/cvspublic cvs co jakarta-servletapi-5 cvs co jakarta-tomcat-5 cvs co jakarta-tomcat-catalina cvs co jakarta-tomcat-connectors cvs co jakarta-tomcat-jasper then, in jakarta-tomcat-5 create a build.properties file with the following definition base.path = /home/sdowney/tc5-workspace/depends (replace /home/sdowney/tc5-workspace with path to your workspace. I don't know if relative will work. I stopped dinking when I got my build system to function) You need ant 1.5 to build Tomcat 5 export ANT_HOME=/home/sdowney/tools/jakarta-ant-1.5 PATH=$PATH:$ANT_HOME/bin ant download The download target in Tomcat 5 gets the necessary ancillary libraries to build the system. I'm using JDK 1.4, which has a few things built in. You may need to install some things in JDK 1.3, like JCE. I'm not sure. Then: ant build ant test [Not many tests at the moment] If you're contributing, you may also want to do ant -Dfull.dist=on build That will force a full compile, rather than checking which optional components are available and setting things on or off based on the presense or absense of classes. That useful for building a customized version, but for testing purposes, a full build is better. To run the watchdog conformance test suite: ant watchdog -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Christian Gross Software Engineering Consultant http://www.devspace.com North America: 1-450-675-4208 Europe +41.1.701.1166 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 4.1.12 and Servlet Access 404 Errors: BUG? One Last Assurance
About this issue, I already pointed it out by commenting to JSR-154 servlet 2.4. Actually invoker-like features in web containers have provided servlet deployers with non-standard ways to invoke a servlet by sending a request message including /servlet/fully-qualified-class-name-of-a-servlet. A few months ago I found that an initial invoker-style call to a servlet also made an instance from the servlet class and there was no identification (or name) of the instance because invoker-style let a servlet deployer care about nothing with servlet name-servlet class mapping in deployment descriptor. I called the instance implicitly initiated servlet instance and told JSR-154 the ambiguity. Now, I realized that the problem stems from the existence of the real invoker in Tomcat and servlet deployers have taken it for granted. However, from Tomcat 4.1.12 and 4.0.5 we need a de facto principle on servlet name-servlet class-servlet mapping relationship. Principle: A servlet (class) should have a servlet name and a servlet mapping associated with that. In my opinion, servlet spec (possibly 2.4) has to mention the above statement in order to get rid of the ambiguity and obtain some clarity that will assure the relationship among servlet class, name, and mapping for not only servlet deployers but also servlet container implementors. At this moment, I'd like to say that we need a clearer statement. What I'm proposing is: A servlet (class) should have at least one servlet name and correspondent mapping for invocation. At a mathematical point of view, mapping from servlet class to servlet name is one-to-many. (conversely, servlet name to servlet class is injective.) This means a servlet class can have many servlet names, but a servlet name cannot be mapped to different servlet classes naturally. servlet name and servlet mapping goes the same road as well. Conclusion: servlet class -- one-to-many -- servlet name -- one-to-many -- servlet mapping Here's a typical example: ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app servlet servlet-nameias/servlet-name servlet-classiasandcb.TestServlet/servlet-class /servlet servlet servlet-namecb/servlet-name servlet-classiasandcb.TestServlet/servlet-class /servlet servlet-mapping servlet-nameias/servlet-name url-pattern/servlet/iasandcb.TestServlet/url-pattern /servlet-mapping servlet-mapping servlet-nameias/servlet-name url-pattern/servlet/TestServlet/url-pattern /servlet-mapping servlet-mapping servlet-namecb/servlet-name url-pattern/servlet/cb/url-pattern /servlet-mapping servlet-mapping servlet-namecb/servlet-name url-pattern/cb/url-pattern /servlet-mapping /web-app In this case, we have one servlet class iasandcb.TestServlet and it has two servlet name ias and cb. Finally the names have two servlet mappings respectively, therefore we have four ways to invoke the servlet. http://localhost:8080/test/servlet/iasandcb.TestServlet (invoker style) http://localhost:8080/test/servlet/TestServlet http://localhost:8080/test/servlet/cb http://localhost:8080/test/cb Formula: the number of the invocation ways of a servlet = sum (the number of the servlet mappings) for each servlet name of the servlet (The above case, 4 = 2 + 2) I hope servlet spec and implementations can get more portablity and security from this chance. -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 03, 2002 12:39 AM To: Tomcat Developers List Subject: Re: Tomcat 4.1.12 and Servlet Access 404 Errors: BUG? One Last Assurance On Wed, 2 Oct 2002, micael wrote: Date: Wed, 02 Oct 2002 00:12:20 -0700 From: micael [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: Tomcat 4.1.12 and Servlet Access 404 Errors: BUG? One Last Assurance So I can understand, where is the difference in the code between Tomcat 4.1.10 and 4.1.12? And, do you mean that servlet mappings rather than being generic to some servlet/* path be individualized? Let's assume that you have two servlets that are currently accessed via the following URLs: http://localhost:8080/myapp/servlet/com.mypackage.MyFooServlet http://localhost:8080/myapp/servlet/com.mypackage.MyBarServlet that no longer work in 4.1.12. To avoid changing all your URLs, you have two basic choices: (1) Re-enable the invoker servlet by uncommenting the /servlet/* mapping in $CATALINA_HOME/conf/web.xml (non-portable, might be open to future vulnerabilities) (2) Explicitly add servlet definitions and mappings for these two servlets: web-app servlet servlet-nameFoo/servlet-name servlet-classcom.mypackage.MyFooServlet/servlet-class /servlet servlet servlet-nameBar/servlet-name
DO NOT REPLY [Bug 13231] New: - web container not sending back content type if html META is in JSP
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=13231. 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=13231 web container not sending back content type if html META is in JSP Summary: web container not sending back content type if html META is in JSP Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Connector:Other AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] adding the following meta tag to the JSP META http-equiv=Content-Type content=text/html; charset=GB2312 does not cause internet explorer to auto-select the encoding as gb2312. putting %@ page contentType=text/html; charset=gb2312% at the top of the JSP will cause internet explorer to auto-select the encoding as gb2312 though. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13231] - web container not sending back content type if html META is in JSP
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=13231. 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=13231 web container not sending back content type if html META is in JSP [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 05:17 --- You'll have to take this up with Microsoft. It's their product. The %@page directive is the only method to specify the charset within Tomcat. -- 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
billbarker2002/10/02 22:24:06
Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
Log:
Send the proper header for HTTP/1.0 Keep-Alives.
If we're going to support it, we should do it right.
Fix for bug #12783
Reported By: [EMAIL PROTECTED]
Submitted By: C Twomey [EMAIL PROTECTED]
Revision ChangesPath
1.38 +2 -0
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.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- Http11Processor.java 21 Sep 2002 06:15:50 - 1.37
+++ Http11Processor.java 3 Oct 2002 05:24:06 - 1.38
@@ -895,6 +895,8 @@
if (!keepAlive) {
response.addHeader(Connection, close);
+} else if(!http11) {
+response.addHeader(Connection, Keep-Alive);
}
// Build the response header
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12783] - Coyote Connector and HTTP 1.0 Keep-Alive
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=12783. 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=12783 Coyote Connector and HTTP 1.0 Keep-Alive [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 05:25 --- The patch has been applied, and will appear in 4.1.13. Thanks much! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13231] - web container not sending back content type if html META is in JSP
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=13231. 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=13231 web container not sending back content type if html META is in JSP [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-10-03 06:18 --- same thing happens when Netscape is used. The same bug does not occur when IE and Netscape are used to access the same pages served by other appservers from IPlanet, Weblogic, Oracle. If the response html (of the JSP) is saved into a .html and reopened in either browser, auto-selecting of the encoding as gb2312 occurs. I suspect that the HTTP response returned by tomcat remains at Content-Type: text/html;charset=ISO-8859-1 even though the html META is present, forcing the browser to use the ISO encoding. would appreciate if you will look into this, or forward it to the correct module I/C, cos' it quite irritating to have to change the encoding manually upon every page access. thanks. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JK 1.2.0 binaries for iSeries
Well it may be a premiere on Apache.
You could find an iSeries binary at:
http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/bin/iseries/
It's an OS400 SAVF, built on V5R1, but should works on V5R2,
which is zipped to save place.
On V5R1/V5R2 you should have the latest Apache 2.0 PTFs installed, the
one's which provide Apache 2.0.39.
Quicks instructions :
- Unzip MOD_JK.zip on you workstation (PC/Unix) and will get a MOD_JK.SAVF.
- Go to iSeries, create a SAVF enveloppe, ie :
CRTSAVF FILE(MYLIB/MOD_JK) TEXT('MOD_JK VERSION 1.2.0 iSeries')
- Send the MOD_JK file via ftp in binary into MYLIB.
- on iSeries restore SAVF :
RSTLIB SAVLIB(MOD_JK) DEV(*SAVF) SAVF(MYLIB/MOD_JK)
- You could use the new MOD_JK Apache module from the MOD_JK
library :
# Apache Default server configuration
# LoadModule jk_module /QSYS.LIB/QHTTPSVR.LIB/QZTCJK.SRVPGM
LoadModule jk_module /QSYS.LIB/MOD_JK.LIB/MOD_JK.SRVPGM
- Or if you want to have it next to others Apache modules,
you should copy the MOD_JK.SRVPGM to iSeries Apache 2.0.39
module library :
CRTDUPOBJ OBJ(MOD_JK) FROMLIB(MOD_JK) OBJTYPE(*SRVPGM)
TOLIB(QHTTPSVR) NEWOBJ(MOD_JK)
MOD_JK SRVPGM is now installed on iSeries Apache modules :
- You should next add MOD_JK module to one of your Apache Server
instance by editing the Server Configuration and commenting
IBM provided MOD_JK (QZTCJK.SRVPGM)
# Apache Default server configuration
# LoadModule jk_module /QSYS.LIB/QHTTPSVR.LIB/QZTCJK.SRVPGM
LoadModule jk_module /QSYS.LIB/QHTTPSVR.LIB/MOD_JK.SRVPGM
...
I recommand you to read the documentation about configuring
Apache 2.0 on iSeries at :
http://www-1.ibm.com/servers/eserver/iseries/software/http/product/gui.html
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 4.1.12 JSPC question
Here is a bit more information. I took a look at the jar files for jsp 1.1 tags and they include a taglib.tld file in meta-inf/. Once I remove that, it compiles the pages fine. It looks like there's a conflict in either jasper compiler or jspc that is unable to resolve which .tld file to use. peter lin peter lin wrote: after a lot of digging, I tracked part of the problem down to jakarta string taglib. once I removed that from my file, it correctly compiles the jsp page. I'm working on tracking down the exact cause, but it might be an issue with jsp 1.1 tags. JSTL 1.2 compliant, but string taglib is 1.1. if anyone has seen this, I'd like to hear about it. it might help me diagnose the problem and find a fix faster. peter -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
