DO NOT REPLY [Bug 11845] New: - Session sometimes times out
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=11845. 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=11845 Session sometimes times out Summary: Session sometimes times out Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, I have a complex web application running on a Tomcat Standalone with the standard HTTP-Connector. The session timeout is set in the web.xml to 120. Sometimes the session timed out after only a few minutes. Normally it works without any problems. When the timeout occurs I haven't made any changes on the server (copying classes JSP'S, ...) This is an extract from the access log: 192.168.192.103 - rootadmin [19/Aug/2002:14:57:38 1000] GET /proB/jsp/rbac_objects/companyUserList.jsp?oid=133 HTTP/1.1 200 1073 192.168.192.103 - - [19/Aug/2002:14:59:33 1000] GET /proB/jsp/containers/htmlTree.jsp?cmd=4oid=10_133 HTTP/1.1 302 654 The user hasn't closed the browser. I see no reason why the session times out. I know that's not much information for searching a bug. But I can't reproduce the problem. It only occurs sometimes (about 1 from 100 sessions). Best regards, Martin Hengesbach -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11846] New: - Class loader problem
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=11846. 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=11846 Class loader problem Summary: Class loader problem Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Minor Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have a CORBA Client-side API ( used with VisiBroker 4.5 ) used to access remote resources from my web server. In order to use this API, I have placed the VisiBroker's vbjorb.jar file in my WebApp/lib directory. With the former release of Tomcat i.e. 4.0, everything worked marvelously well. But when I tried to install everything on 4.0.4, there were some class-loading problems. What are the differences between 4.0 and 4.0.4 regarding class-loading??? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11849] New: - Nested includes with JSTL1.0EA do 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=11849. 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=11849 Nested includes with JSTL1.0EA do not work Summary: Nested includes with JSTL1.0EA do not work Product: Tomcat 4 Version: 4.1.9 Platform: Sun OS/Version: Solaris Status: NEW Severity: Blocker Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am using the JSTL1.0 EA to include pages with c:import. My front page imports a header and another page, which in turn imports two other pages, like main.jsp: c:import url=header.jsp/ c:import url=workspace.jsp/ workspace.jsp: c:import url=left.jsp/ c:import url=right.jsp/ left.jsp: c:import url=tree.jsp/ right.jsp: c:import url=selection.jsp/ With Tomcat 4.1.3 everything is included and displayed correctly, but with Tomcat 4.1.7 and Tomcat 4.1.9 the imports in left.jsp and right.jsp return the header.jsp instead of the correct files (tree.jsp and selection.jsp). (If I knew how to do it with this GUI, I'd include a screen shot). This bug makes Tomcat 4.1.7 and greater unusable for me. Best regards Georg -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Releases not being signed any more?
I see that Tomcat binary releases after 3.3.1 do not have accompanying digital signatures from the developers. I have scoured the mailing list archives and FAQ's and I can't see where the signatures have been moved or why they are not there. Are they there where I haven't looked, or has the release signing procedure been discontinued? I am interested because of the recent spate of FTP server hacking - OpenSSH just the other week. I have to be careful of what I install on my employer's network, and Tomcat is not a good place to have a trojan inserted. Thanks for the excellent software. Graham - Graham Chapman Email : [EMAIL PROTECTED] Web : http://patia.com/grahamc -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11849] - Nested includes with JSTL1.0EA do 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=11849. 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=11849 Nested includes with JSTL1.0EA do not work --- Additional Comments From [EMAIL PROTECTED] 2002-08-20 08:08 --- Created an attachment (id=2770) Screen shot of broken imports in Tomcat 4.1.9 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11849] - Nested includes with JSTL1.0EA do 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=11849. 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=11849 Nested includes with JSTL1.0EA do not work --- Additional Comments From [EMAIL PROTECTED] 2002-08-20 08:08 --- Created an attachment (id=2771) Correct screen using Tomcat 4.1.3 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Strange delays while Tomcat works
-Original Message- From: Dev Zero G Ltd [mailto:[EMAIL PROTECTED]] Sent: Monday, August 19, 2002 9:31 PM To: Tomcat Developers List Subject: Strange delays while Tomcat works If your processor load is low during those delays then it seems to me that you have a problems like a network name to IP resolvings. Try to eliminate all the 'named' resources to IP based. we have) - for aproximately 5-6 seconds, and processes JSP page. The very strange behavior aoccurs right there - custom tags may be executed for 2,3,6 or even 10 seconds. In other time, after executing part of JSP page, debug output stops, and continues after 2-3 seconds. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jtc rpms
Quoting Bojan Smojver [EMAIL PROTECTED]: On Tue, 2002-08-20 at 00:50, Henri Gomez wrote: Welcome back from holidays, Thanks hope you had a good time... Rainy ;[ I propose to create a snapshot subdir in jtc, snapshot, and provide here the necessary binaries, for example Linux rpms .so, windows, netware, iis are welcome also. http://jakarta.apache.org/builds/jakarta-tomcat-connectors/snapshot/rpms/ We could have right now : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/snapshot/v4.1.9-beta/ rpms/ What do you think about that ? I think this is generally a good idea but I just wanted to clear another possible source of confusion. Is there some sort of dependency between modules and Apache 2.0.x versions? Yes, with latest Apache 2.0, modules should be compiled against the proper Apache 2.0, so if you have a mod_jk built against 2.0.39, you need to recompile it to make use of jk under Apache 2.0.40 ;( It will be a pain for many distributions and modules maintainers (binary), so I hope HTTP 2.0 team will relax it a little or consider version update and functionnalities updates. I ran into this with mod_jk 1.2.0 from CVS (i.e. had to rebuild the module when the version of Apache was bumped from 2.0.39 to 2.0.40). I almost always do static linking, but I was wandering if that applies to DSO's as well (my experience with building PHP 4.2.2 tells me it does). If so, I think we should also clearly mark what Apache version that particular module is for. Yes, ie mod_jk-1.2.0-apache-2.0.40.so Also, do we need to tie JTC to a particular Tomcat version, like in your example to 4.1.9? It didn't tie to tomcat version but rather to jtc snapshot ;) My understanding is that the web server (Apache) part doesn't care much about what's behind it, as long as it speaks the correct protocol version. Maybe there should be a README file instead, listing all known Tomcat version combos for a particular JTC version... I agree, and we refer to the jtc tag name instead of a particular tomcat version. You could use mod_jk 1.2.0 tagged at tc 4.1.9 time with tc 3.3.1 regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Modified stop-script for Linux
Quoting Alex Chaffee / Purple Technology [EMAIL PROTECTED]: Thanks! I added it to the recently-posted Bug 11754. You may want to add yourself as a CC on this to track its progress. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11754 Thanks also. I applied the patch to the 4.1.9 rpm I'm working on. Stay tuned :) - A On Mon, Aug 19, 2002 at 09:57:31AM +0200, Golden Planet Support wrote: Hello All I have noticed that the /etc/init.d/tomcat4 script still contains what is described as an Ugly hack - a short two second pause when restarting the service instead of something that confirms that all threads have been shut down. A while ago I modified my own script to conatain the following lines - perhaps they could be of some use for others, I don't know. I am by no means an experienced coder so please bear with me if this is not the most elegant solution - it just works for me... ;-) stop() { echo -n Stopping $TOMCAT_PROG: if [ -x /etc/rc.d/init.d/functions ]; then daemon --user $TOMCAT_USER $TOMCAT_SCRIPT stop else su - $TOMCAT_USER -c $TOMCAT_SCRIPT stop fi RETVAL=$? echo echo 'Waiting for java threads to finish...' threads=1 until [ $threads = '0' ] do ps -aux | grep $TOMCAT_USER -c /tmp/threads read threads /tmp/threads done rm -f /tmp/threads echo 'Java threads cleaned up - shutdown complete.' [ $RETVAL = 0 ] rm -f /var/lock/subsys/tomcat4 /var/run/tomcat4.pid } The above works on a x86 RedHat 7.1 - I don't know if things may work differently on other systems. -- Med venlig hilsen / Best regards Anders C. Madsen Golden Planet Tel.: +45 7020 9594 Dalbygade 40 Fax.: +45 7020 9592 DK-6000 Kolding http://www.goldenplanet.dk -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Alex Chaffee mailto:[EMAIL PROTECTED] jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Modified stop-script for Linux
Henri, You've probably already thought of this but I just wanted to mention that if you're going to do something like this you probably ought not to write to the temp file (instead just storing to a threads variable directly like threads=$(ps auxwww | grep $TOMCAT_USER -c)) or if there's some reason for writing to a file that I can't see in my tired state at least use mktemp. It would cause a lot less headaches from a malicious local user/race condition perspective. Jason -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED]] Sent: Tue 8/20/2002 4:57 AM To: Tomcat Developers List; [EMAIL PROTECTED] Cc: Subject:Re: Modified stop-script for Linux Quoting Alex Chaffee / Purple Technology [EMAIL PROTECTED]: Thanks! I added it to the recently-posted Bug 11754. You may want to add yourself as a CC on this to track its progress. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11754 Thanks also. I applied the patch to the 4.1.9 rpm I'm working on. Stay tuned :) - A On Mon, Aug 19, 2002 at 09:57:31AM +0200, Golden Planet Support wrote: Hello All I have noticed that the /etc/init.d/tomcat4 script still contains what is described as an Ugly hack - a short two second pause when restarting the service instead of something that confirms that all threads have been shut down. A while ago I modified my own script to conatain the following lines - perhaps they could be of some use for others, I don't know. I am by no means an experienced coder so please bear with me if this is not the most elegant solution - it just works for me... ;-) stop() { echo -n Stopping $TOMCAT_PROG: if [ -x /etc/rc.d/init.d/functions ]; then daemon --user $TOMCAT_USER $TOMCAT_SCRIPT stop else su - $TOMCAT_USER -c $TOMCAT_SCRIPT stop fi RETVAL=$? echo echo 'Waiting for java threads to finish...' threads=1 until [ $threads = '0' ] do ps -aux | grep $TOMCAT_USER -c /tmp/threads read threads /tmp/threads done rm -f /tmp/threads echo 'Java threads cleaned up - shutdown complete.' [ $RETVAL = 0 ] rm -f /var/lock/subsys/tomcat4 /var/run/tomcat4.pid } The above works on a x86 RedHat 7.1 - I don't know if things may work differently on other systems. -- Med venlig hilsen / Best regards Anders C. Madsen Golden Planet Tel.: +45 7020 9594 Dalbygade 40 Fax.: +45 7020 9592 DK-6000 Kolding http://www.goldenplanet.dk -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Alex Chaffee mailto:[EMAIL PROTECTED] jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] winmail.dat -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: jasper package
The compiler driver and classloader used by tomcat does a lot of magic to get it to work. All jsp files named, for example, Yes I know the class loader has the job done, is it bearking the convention? Anyway, I can debug my jsp now with the jasper I patched. Yunfeng Hou _ Do You Yahoo!? ÐÂÏʵ½µ×,ÓéÀÖµ½¼Ò - ÑÅ»¢ÍƳöÃâ·ÑÓéÀÖµç×ÓÖܱ¨! http://cn.ent.yahoo.com/newsletter/index.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jtc rpms
On Tue, 2002-08-20 at 18:56, Henri Gomez wrote: Quoting Bojan Smojver [EMAIL PROTECTED]: On Tue, 2002-08-20 at 00:50, Henri Gomez wrote: Welcome back from holidays, Thanks hope you had a good time... Rainy ;[ Sorry to hear that :-( Yes, with latest Apache 2.0, modules should be compiled against the proper Apache 2.0, so if you have a mod_jk built against 2.0.39, you need to recompile it to make use of jk under Apache 2.0.40 ;( It will be a pain for many distributions and modules maintainers (binary), so I hope HTTP 2.0 team will relax it a little or consider version update and functionnalities updates. I was hoping it was a temporary thing. Otherwise it truly looked like a nightmare... Yes, ie mod_jk-1.2.0-apache-2.0.40.so Yep, exactly. I agree, and we refer to the jtc tag name instead of a particular tomcat version. You could use mod_jk 1.2.0 tagged at tc 4.1.9 time with tc 3.3.1 That's right. On packaging, the file explaining the compatibility might also be included in the RPM itself. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jasper package
The Java compiler used by Tomcat doesn't have any problems compiling the sources that are currently being generated. What compiler are you trying to use that has problems with it? That's where your problem really appears to lie. Yes, because the magic class loader has the tricky work done. Still, the package name of the generated class and the directory it resides are not consistent. It makes debug impossible. Here's what Sysdeo - a tomcat plugin for eclipse, says how to debug jsp. (http://www.sysdeo.com/eclipse/tomcatPlugin.html) Workaround 1 : install our Tomcat 4.x patch. Workaround 2 (from Gabriel Krupa) : if your jsp is /myjspdir/myjsp.jsp, generated servlet will be in work/org/apache/jsp/myjspdir, change package definition from org.apache.jsp to org.apache.jsp.myjspdir, to debug your jsp access it from your browser with the following URL : http://myhost:8080/myapplication/servlets/org.apache.jsp.myjspdir.myjsp$jsp Workaround 3 : use Tomcat 3.3 (servlet 2.2 and JSP 1.1), with Tomcat 3, package definition is compliant with file location. Yunfeng Hou _ Do You Yahoo!? ÐÂÏʵ½µ×,ÓéÀÖµ½¼Ò - ÑÅ»¢ÍƳöÃâ·ÑÓéÀÖµç×ÓÖܱ¨! http://cn.ent.yahoo.com/newsletter/index.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6279] - Resubmit to j_security_check mistakenly fetches a page of that name
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=6279. 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=6279 Resubmit to j_security_check mistakenly fetches a page of that name --- Additional Comments From [EMAIL PROTECTED] 2002-08-20 12:42 --- This bug happens in version 4.0.3 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Jasper 2 jspc.bat and JspC.class
I have been working on JspC.java to have it generate the .class files in the same directory structure that the jsp files are in ie /root/dir/test.jsp -- /root/dir/test_jsp.java -- /root/dir/test_jsp.class this is for compiling a webapp vs one file at a time. The problem I have encountered is that the compiler tries to compile a jsp that is used as a Include Directive. This fails the compile. Is there anyway I can detect this as to skip these files. Thanks, John -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Fwd: Tomcat 4.03 / 4.04 source download incorrect.
Not acked Begin forwarded message: From: Lukas Hazlehurst [EMAIL PROTECTED] Date: Wed Aug 14, 2002 01:05:07 Europe/London To: [EMAIL PROTECTED] Subject: Tomcat 4.03 / 4.04 source download incorrect. Hello, Just thought i'd mention that the link onhttp://jakarta.apache.org/site/sourceindex.html to the source download for tomcat 4.03 is dead and (i'm guessing) needs to be changed to 4.04. The link works fine if you change the url to ...release/v4.0.4/src/ You guys do an amazing job btw. Lukas Sofnology Ltd. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: VOTE: Restoring Tomcat examples: Which workspace?
Humm. Are the examples Tomcat specific or should they work in any JSP2.0 and Servlet 2.4 container? If they are generic then perhaps keeping them separate would encourage their reuse with other JSP/Servlet projects. Shouldn't every jsp server have a decent Snoop.jsp ? Cheers, -bob On Mon, 2002-08-19 at 16:47, Mark Roth wrote: It would be great to restore the examples (both JSP and Servlet) so that they are deployed on startup and so they are easily accessible. In the current build they are broken links. I also would like to commit a number of additional JSP examples that illustrate the new features in JSP 2.0. The default web application that is deployed on startup currently lives in the catalina workspace. I have no problems keeping it there, but before committing such a change I wanted to take a vote on where we think the examples should live. Vote: [ ] A. jakarta-tomcat-catalina [ ] B. jakarta-tomcat-jasper [ ] C. jakarta-tomcat-5 -- Mark Roth, Java Software Co-Specification Lead for JSP 2.0 Sun Microsystems, Inc. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Cheers, -bob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Fwd: Minor bug in Tomcat docs
Not acked. Begin forwarded message: From: Asuja Andreas [EMAIL PROTECTED] Date: Fri Aug 16, 2002 09:09:44 Europe/London To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: Minor bug in Tomcat docs Hi! On page http://jakarta.apache.org/tomcat/tomcat-4.1-doc/appdev/deployment.html Under heading Shared Library Files it says: $CATALINA_HOME/shared/lib - JAR files placed here are visible to all web applications, but not to internal Tomcat code. This is the right place for shared libraries that are specific to your application. But on page http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html Under heading Class Loader Definitions = Shared Is said: All unpacked classes and resources in $CATALINA_HOME/shared/classes, as well as classes and resources in JAR files under $CATALINA_HOME/lib, are made visible through this class loader. The latter seems to be correct, but the former isn't true as Tomcat doesn't read libraries from $CATALINA_HOME/shared/lib. Yours, Andreas -- Andreas Asuja Fujitsu Invia, Finland Tel +358 10 599 4167 Fax +358 9 424651044 [EMAIL PROTECTED], http://invia.fujitsu.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Fwd: Broken link
Not acked Begin forwarded message: From: Jørgen Nørgaard [EMAIL PROTECTED] Date: Tue Aug 20, 2002 14:17:23 Europe/London To: [EMAIL PROTECTED] Subject: Broken link On http://jakarta.apache.org/site/sourceindex.html there is a link to Tomcat 4.0.2 srcs (http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.3/ src/) that appears to be broken? Regards -- /jørgen nørgaard [EMAIL PROTECTED] Phone: +45 3332 5770 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11849] - Nested includes with JSTL1.0EA do 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=11849. 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=11849 Nested includes with JSTL1.0EA do not work --- Additional Comments From [EMAIL PROTECTED] 2002-08-20 13:50 --- BTW: I am using the JDK 1.4.0. Found other bug reports complaining about JSP compiler failing on many JSTL tags in 4.0.4. Those are still open. Any hope that this is fixed in the nightly build? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: VOTE: Restoring Tomcat examples: Which workspace?
The examples, just as in Tomcat 4, are small, portable JSP / Servlet examples to illustrate how to use these technologies. Because Tomcat forms the basis of the RI for Servlet/JSP, and because it is so easy to use, many developers download it to try their hand at Servlet/JSP development. I thought it was great how Tomcat 4 provided a set of pre-deployed examples, ready to go as soon as the server starts up. We should continue this for Tomcat 5 (right now the examples links are broken). The only question is which workspace to keep them in. Vote: [ ] A. jakarta-tomcat-catalina [ ] B. jakarta-tomcat-jasper [ ] C. jakarta-tomcat-5 - Mark On Tue, 2002-08-20 at 09:40, Bob Herrmann wrote: Humm. Are the examples Tomcat specific or should they work in any JSP2.0 and Servlet 2.4 container? If they are generic then perhaps keeping them separate would encourage their reuse with other JSP/Servlet projects. Shouldn't every jsp server have a decent Snoop.jsp ? Cheers, -bob On Mon, 2002-08-19 at 16:47, Mark Roth wrote: It would be great to restore the examples (both JSP and Servlet) so that they are deployed on startup and so they are easily accessible. In the current build they are broken links. I also would like to commit a number of additional JSP examples that illustrate the new features in JSP 2.0. The default web application that is deployed on startup currently lives in the catalina workspace. I have no problems keeping it there, but before committing such a change I wanted to take a vote on where we think the examples should live. Vote: [ ] A. jakarta-tomcat-catalina [ ] B. jakarta-tomcat-jasper [ ] C. jakarta-tomcat-5 -- Mark Roth, Java Software Co-Specification Lead for JSP 2.0 Sun Microsystems, Inc. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Cheers, -bob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Mark Roth, Java Software Sun Microsystems, Inc. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11859] New: - JSP generation of binary files 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=11859. 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=11859 JSP generation of binary files not possible Summary: JSP generation of binary files not possible Product: Tomcat 4 Version: 4.1.9 Platform: Other OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have tags, which generate excel. They write data to servlet's output stream. Servlet generated by Jasper is taking output writer automatically and sometimes is pushing '\n' character to it (without any reason). It causes the problem. [Note: This tags were working for tomcat 3.2 and tomcat 3.3] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 BUILDING.txt build.properties.default
patrickl2002/08/20 07:50:02 Modified:.BUILDING.txt build.properties.default Log: Correct Digester build. The changes we need did not show up in 200020819 nightly build. Revision ChangesPath 1.22 +2 -2 jakarta-tomcat-5/BUILDING.txt Index: BUILDING.txt === RCS file: /home/cvs/jakarta-tomcat-5/BUILDING.txt,v retrieving revision 1.21 retrieving revision 1.22 diff -u -r1.21 -r1.22 --- BUILDING.txt 20 Aug 2002 01:42:52 - 1.21 +++ BUILDING.txt 20 Aug 2002 14:50:02 - 1.22 @@ -217,7 +217,7 @@ (8) Download and Install the Commons Digester Binary Distribution -* Download a binary distribution (version 20020819 or later) from: +* Download a binary distribution (version 20020820 or later) from: http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester 1.31 +2 -2 jakarta-tomcat-5/build.properties.default Index: build.properties.default === RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- build.properties.default 20 Aug 2002 01:42:52 - 1.30 +++ build.properties.default 20 Aug 2002 14:50:02 - 1.31 @@ -72,7 +72,7 @@ commons-daemon.loc=jakarta-commons-sandbox/daemon -# - Commons Digester, version 20020819 or later - +# - Commons Digester, version 20020820 or later - commons-digester.home=${base.path}/commons-digester commons-digester.lib=${commons-digester.home}/dist commons-digester.jar=${commons-digester.lib}/commons-digester.jar -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
build err on tc 4.1.9
I've got the following error when building TC 4.1.9 build-main: [javac] Compiling 161 source files to /usr/src/redhat/BUILD/tomcat4-4.1.9/jakarta-tomcat-4.1.9-src/webapps/build/admin/WEB-INF/classes [javac] Found 2 semantic errors compiling /usr/src/redhat/BUILD/tomcat4-4.1.9/jakarta-tomcat-4.1.9-src/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TomcatTreeBuilder.java: [javac]128. mBServer = servlet.getServer(); [javac]--- [javac] *** Error: You need to modify your classpath, sourcepath, bootclasspath, and/or extdirs setup. Package javax/sql could not be found in: [javac] /opt/IBMJava2-131/jre/lib/ext/ibmjcaprovider.jar [javac] /opt/IBMJava2-131/jre/lib/ext/jaas.jar [javac] /opt/IBMJava2-131/jre/lib/ext/jaas_lm.jar [javac] /opt/IBMJava2-131/jre/lib/ext/comm.jar [javac] /opt/IBMJava2-131/jre/lib/ext/indicim.jar [javac] /usr/src/redhat/BUILD/tomcat4-4.1.9/jakarta-tomcat-4.1.9-src/webapps/build/admin/WEB-INF/classes [javac] /usr/share/java/commons-modeler.jar [javac] /usr/share/java/mx4j.jar [javac] /usr/share/java/servlet-2.3.jar [javac] /usr/share/java/struts.jar [javac] /usr/share/java/xml-commons-apis.jar [javac] /usr/share/java/jaxp_parser_impl.jar [javac] /usr/share/java/ant-optional.jar [javac] /usr/share/java/ant.jar [javac] /usr/share/java/xalan-j2.jar [javac] /opt/IBMJava2-131/lib/tools.jar [javac] /opt/IBMJava2-131/jre/lib/rt.jar [javac] /usr/src/redhat/BUILD/tomcat4-4.1.9/jakarta-tomcat-4.1.9-src/webapps/admin/WEB-INF/classes [javac] . [javac]128. mBServer = servlet.getServer(); [javac]--- [javac] *** Error: Type javax/sql/DataSource was not found. BUILD FAILED file:/usr/src/redhat/BUILD/tomcat4-4.1.9/jakarta-tomcat-4.1.9-src/webapps/admin/build.xml:179: Compile failed; see the compiler error output for details. Total time: 55 seconds error: Bad exit status from /var/tmp/rpm-tmp.53791 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.53791 (%build) What's the problem with javax/sql/DataSource for a MBeanServer ? Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11859] - JSP generation of binary files 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=11859. 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=11859 JSP generation of binary files not possible [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-08-20 14:56 --- Sorry, but it is a bug in Tomcat 3.2 and 3.3 that writing binary data is possible. I'm not sure about the various versions of Tomcat4. The JSP spec requires that the JspWriter be associated with a PrintWriter in the ServletResponse, thus precluding use of an OutputStream to output binary. It is a bug in Tomcat3 that this isn't enforced. To output binary, your JSP may need to forward to a servlet to perform the output. The JSP spec also requires that all template text be output verbatim. Thus, there is a '\n' of template text between the following two scriptlets if formatted as follows: % script1 % % script2 % I assume something like this is the cause for the '\n' characters. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11865] New: - forward from root context always fails
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=11865. 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=11865 forward from root context always fails Summary: forward from root context always fails Product: Tomcat 4 Version: 4.0.4 Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Attempting to forward from the root context to another context always fails Here are the steps to replicate this problem: 1. Modify server.xml by adding the following: Context path= docBase=ROOT debug=0 crossContext=true/ Context path=/context1 docBase=context1 debug=0 crossContext=true/ Context path=/context2 docBase=context2 debug=0 crossContext=true/ 2. Create the following jsp files: /index.jsp and /context1/context1.jsp: % getServletContext().getContext(/context2).getRequestDispatcher (/context2.jsp).forward(request, response); % /context2/context2.jsp: This is context2.jsp 3. Try to access http://localhost:8080/context1/context1.jsp and notice that this successfully forwards to /context2/context2.jsp 4. Try to access http://localhost:8080 or http://localhost:8080/index.jsp and notice that this fails even though /index.jsp contains the same code as /context1/context1.jsp I believe (although I have not tested this) that the error lies in the file /catalina/src/share/org/apache/catalina/core/ApplicationContext.java lines 440-448: 440 441 // Return the current context if requested 442 String contextPath = context.getPath(); 443 remm 1.37 if (!contextPath.endsWith(/)) 444 contextPath = contextPath + /; 445 if ((contextPath.length() 0) (uri.startsWith (contextPath))) { 446 pier 1.29 return (this); 447 } 448 It seems like the above code will always return the current context of / when forwarding from / since all uri's start with / I believe this may have been working in version 1.36 of the file ApplicationContext.java but stopped working in version 1.37 (the test used to be uri.equals instead of uri.startsWith). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11798] - use of response.flushBuffer in .jsp script results in unterminated HTTP response/ browser hangs
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=11798. 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=11798 use of response.flushBuffer in .jsp script results in unterminated HTTP response/ browser hangs [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-08-20 15:41 --- The response generated by Tomcat is valid, and the connection handling is also correct. Please use a working web browser or point out to an incorrect behavior of Tomcat. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: VOTE: Restoring Tomcat examples: Which workspace?
Mark Roth wrote: It would be great to restore the examples (both JSP and Servlet) so that they are deployed on startup and so they are easily accessible. In the current build they are broken links. I also would like to commit a number of additional JSP examples that illustrate the new features in JSP 2.0. The default web application that is deployed on startup currently lives in the catalina workspace. I have no problems keeping it there, but before committing such a change I wanted to take a vote on where we think the examples should live. Vote: [ ] A. jakarta-tomcat-catalina [ ] B. jakarta-tomcat-jasper [ ] C. jakarta-tomcat-5 The examples are portable and independent of Tomcat, so I want them to go into jakarta-servletapi-5. I posted some time ago about that, and I was planning to do it. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11849] - Nested includes with JSTL1.0EA do 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=11849. 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=11849 Nested includes with JSTL1.0EA do not work --- Additional Comments From [EMAIL PROTECTED] 2002-08-20 15:45 --- I think this is a JSTL bug, with this tag being incompatible with tag reuse (ie, it's not spec compliant). Can someone confirm ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
kinman 2002/08/20 08:50:23 Modified:jasper2/src/share/org/apache/jasper JspC.java jasper2/src/share/org/apache/jasper/compiler Generator.java ImplicitTagLibraryInfo.java Parser.java ParserController.java TagFileProcessor.java jasper2/src/share/org/apache/jasper/resources messages.properties Log: - Submitted by Mark Roth: - Implemented the value attribute of jsp:doBody for classic tag handlers. - Stubbed out JspC with getJspConfig() so it compiles. - Added null check for addInclude() to handle the case where there are no preludes or codas. - Now accepts /WEB-INF/tags as well as /WEB-INF/tags/ for tag file default directory. - ParserController now uses path name to determine if the given element is a tag file instead of searching for tag directive. - In a tag file, an attribute directive with a fragment attribute must not allow a rtexprvalue attribute, and must fix its value to true. Fixed implementation to comply with spec. - Fixed preamble and postamble generator for Tag Files. Was not generating declarations, tag handler pools, methods buffer, helper fragment, etc. Generator now shares code between servlet and tag handler pre and post ambles. - Even though spec is not clear that they're required, added implicit objects to doTag() so they are available in tag files. Revision ChangesPath 1.13 +13 -3 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java Index: JspC.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- JspC.java 26 Jun 2002 16:50:38 - 1.12 +++ JspC.java 20 Aug 2002 15:50:22 - 1.13 @@ -75,6 +75,7 @@ import org.apache.jasper.logging.Logger; import org.apache.jasper.logging.JasperLogger; +import org.apache.jasper.compiler.JspConfig; /** * Shell for the jspc compiler. Handles all options associated with the @@ -912,6 +913,15 @@ Constants.jasperLog.setVerbosityLevel(verbosityLevel); } + +/** + * Obtain JSP configuration informantion specified in web.xml. + */ +public JspConfig getJspConfig() { +// XXX - Stubbed out so Jasper compiles. +initServletContext(); +return new JspConfig( context ); +} } 1.72 +240 -97 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java Index: Generator.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v retrieving revision 1.71 retrieving revision 1.72 diff -u -r1.71 -r1.72 --- Generator.java20 Aug 2002 01:42:38 - 1.71 +++ Generator.java20 Aug 2002 15:50:22 - 1.72 @@ -170,6 +170,7 @@ out.println(); page.visit(new DeclarationVisitor()); + out.println(); } /** @@ -329,23 +330,25 @@ } /** - * Generates the beginning of the static portion of the servelet. + * Generate preamble package name + * (shared by servlet and tag handler preamble generation) */ -private void generatePreamble(Node.Nodes page) throws JasperException { - - String servletPackageName = ctxt.getServletPackageName(); - String servletClassName = ctxt.getServletClassName(); - String serviceMethodName = Constants.SERVICE_METHOD_NAME; - - // First the package name: - - if (! .equals(servletPackageName) servletPackageName != null) { - out.printil(package + servletPackageName + ;); +private void genPreamblePackage( String packageName ) +throws JasperException +{ + if (! .equals(packageName) packageName != null) { + out.printil(package + packageName + ;); out.println(); } - - // Generate imports - +} + +/** + * Generate preamble imports + * (shared by servlet and tag handler preamble generation) + */ +private void genPreambleImports() +throws JasperException +{ Iterator iter = pageInfo.getImports().iterator(); while (iter.hasNext()) { out.printin(import ); @@ -353,31 +356,21 @@ out.println(;); } out.println(); +} - // Generate class declaration - - out.printin(public class ); - out.print (servletClassName); - out.print ( extends ); - out.print (pageInfo.getExtends()); -
DO NOT REPLY [Bug 11826] - Error rthrown on Console after configuring Global JNDI resource
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=11826. 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=11826 Error rthrown on Console after configuring Global JNDI resource [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-08-20 15:56 --- If the datasource definition is not valid, this is normal (if a factory exists but fails to return a datasource or throws an exception, this exception will be thrown). Please make sure your datasource definition is correct. If it was saved incorrecly and what is in server.xml is incorrect, then it's a different issue, and you may want to file a different report about the root cause of the problem. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: VOTE: Restoring Tomcat examples: Which workspace?
I'm open to that possibility, as long as we're able to have then automatically deployed in Tomcat 5 builds. Vote: [ ] A. jakarta-tomcat-catalina [ ] B. jakarta-tomcat-jasper [ ] C. jakarta-tomcat-5 [X] D. jakarta-servletapi-5 Given JB and Remy's comments, I change my vote to 'D'. So that's 2 D's. - Mark On Tue, 2002-08-20 at 11:42, Remy Maucherat wrote: Mark Roth wrote: It would be great to restore the examples (both JSP and Servlet) so that they are deployed on startup and so they are easily accessible. In the current build they are broken links. I also would like to commit a number of additional JSP examples that illustrate the new features in JSP 2.0. The default web application that is deployed on startup currently lives in the catalina workspace. I have no problems keeping it there, but before committing such a change I wanted to take a vote on where we think the examples should live. Vote: [ ] A. jakarta-tomcat-catalina [ ] B. jakarta-tomcat-jasper [ ] C. jakarta-tomcat-5 The examples are portable and independent of Tomcat, so I want them to go into jakarta-servletapi-5. I posted some time ago about that, and I was planning to do it. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: VOTE: Restoring Tomcat examples: Which workspace?
On Tue, 2002-08-20 at 11:42, Remy Maucherat wrote: Mark Roth wrote: It would be great to restore the examples (both JSP and Servlet) so that they are deployed on startup and so they are easily accessible. In the current build they are broken links. I also would like to commit a number of additional JSP examples that illustrate the new features in JSP 2.0. The default web application that is deployed on startup currently lives in the catalina workspace. I have no problems keeping it there, but before committing such a change I wanted to take a vote on where we think the examples should live. Vote: [ ] A. jakarta-tomcat-catalina [ ] B. jakarta-tomcat-jasper [ ] C. jakarta-tomcat-5 The examples are portable and independent of Tomcat, so I want them to go into jakarta-servletapi-5. I posted some time ago about that, and I was planning to do it. Remy jakarta-servletapi-5 sounds much better than A, B, or C. Cheers, -bob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.9] Fix for major bugs
David Oxley wrote: Hi Remy, I've just attached some comments to the bug log (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7082) that were posted to the user list a week or so ago. They seem to explain exactly why this is happening. Have a read through and see what you think. I think the root cause of the problem is just that the URLs should be encoded. As I said, this will be fixed after the first stable 4.1.x release to avoid the possibility of introducing new bugs. In more complex scenarios, I suppose other problems can happen, but the stack trace which was attached seemed to hint at a simple issue. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resourcesmessages.properties
Thans, Kin-Man! - Mark On Tue, 2002-08-20 at 11:50, [EMAIL PROTECTED] wrote: kinman 2002/08/20 08:50:23 Modified:jasper2/src/share/org/apache/jasper JspC.java jasper2/src/share/org/apache/jasper/compiler Generator.java ImplicitTagLibraryInfo.java Parser.java ParserController.java TagFileProcessor.java jasper2/src/share/org/apache/jasper/resources messages.properties Log: - Submitted by Mark Roth: - Implemented the value attribute of jsp:doBody for classic tag handlers. - Stubbed out JspC with getJspConfig() so it compiles. - Added null check for addInclude() to handle the case where there are no preludes or codas. - Now accepts /WEB-INF/tags as well as /WEB-INF/tags/ for tag file default directory. - ParserController now uses path name to determine if the given element is a tag file instead of searching for tag directive. - In a tag file, an attribute directive with a fragment attribute must not allow a rtexprvalue attribute, and must fix its value to true. Fixed implementation to comply with spec. - Fixed preamble and postamble generator for Tag Files. Was not generating declarations, tag handler pools, methods buffer, helper fragment, etc. Generator now shares code between servlet and tag handler pre and post ambles. - Even though spec is not clear that they're required, added implicit objects to doTag() so they are available in tag files. Revision ChangesPath 1.13 +13 -3 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java Index: JspC.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- JspC.java 26 Jun 2002 16:50:38 - 1.12 +++ JspC.java 20 Aug 2002 15:50:22 - 1.13 @@ -75,6 +75,7 @@ import org.apache.jasper.logging.Logger; import org.apache.jasper.logging.JasperLogger; +import org.apache.jasper.compiler.JspConfig; /** * Shell for the jspc compiler. Handles all options associated with the @@ -912,6 +913,15 @@ Constants.jasperLog.setVerbosityLevel(verbosityLevel); } + +/** + * Obtain JSP configuration informantion specified in web.xml. + */ +public JspConfig getJspConfig() { +// XXX - Stubbed out so Jasper compiles. +initServletContext(); +return new JspConfig( context ); +} } 1.72 +240 -97 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java Index: Generator.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v retrieving revision 1.71 retrieving revision 1.72 diff -u -r1.71 -r1.72 --- Generator.java 20 Aug 2002 01:42:38 - 1.71 +++ Generator.java 20 Aug 2002 15:50:22 - 1.72 @@ -170,6 +170,7 @@ out.println(); page.visit(new DeclarationVisitor()); + out.println(); } /** @@ -329,23 +330,25 @@ } /** - * Generates the beginning of the static portion of the servelet. + * Generate preamble package name + * (shared by servlet and tag handler preamble generation) */ -private void generatePreamble(Node.Nodes page) throws JasperException { - - String servletPackageName = ctxt.getServletPackageName(); - String servletClassName = ctxt.getServletClassName(); - String serviceMethodName = Constants.SERVICE_METHOD_NAME; - - // First the package name: - - if (! .equals(servletPackageName) servletPackageName != null) { - out.printil(package + servletPackageName + ;); +private void genPreamblePackage( String packageName ) +throws JasperException +{ + if (! .equals(packageName) packageName != null) { + out.printil(package + packageName + ;); out.println(); } - - // Generate imports - +} + +/** + * Generate preamble imports + * (shared by servlet and tag handler preamble generation) + */ +private void genPreambleImports() +throws JasperException +{ Iterator iter = pageInfo.getImports().iterator(); while (iter.hasNext()) { out.printin(import ); @@ -353,31 +356,21 @@ out.println(;); } out.println(); +} - // Generate
Re: VOTE: Restoring Tomcat examples: Which workspace?
Mark Roth wrote: I'm open to that possibility, as long as we're able to have then automatically deployed in Tomcat 5 builds. Yes, I was planning to do that of course. The webapps will be built by the scripts from the jakarta-servletapi-5 repository, and the result will be copied to the webapps folder by the main Tomcat script. I just got a bit lazy after finishing the repackaging in j-s-5, and thought I would do it the next day :-D Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 BUILDING.txt
patrickl2002/08/20 09:14:32 Modified:.BUILDING.txt Log: Correct download info for commons-digester Revision ChangesPath 1.23 +4 -5 jakarta-tomcat-5/BUILDING.txt Index: BUILDING.txt === RCS file: /home/cvs/jakarta-tomcat-5/BUILDING.txt,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- BUILDING.txt 20 Aug 2002 14:50:02 - 1.22 +++ BUILDING.txt 20 Aug 2002 16:14:32 - 1.23 @@ -218,14 +218,13 @@ (8) Download and Install the Commons Digester Binary Distribution * Download a binary distribution (version 20020820 or later) from: - -http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester +http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-digester On a Windows platform, you will need: -commons-digester-X.Y.zip +commons-digester-MMDD.zip On a Unix platform, you will need: -commons-digester-X.Y.tar.gz +commons-digester-MMDD.tar.gz * Unpack the binary distribution into a convenient location so that the distribution resides in its own directory. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: VOTE: Restoring Tomcat examples: Which workspace?
Remy, Remy Maucherat wrote: I just got a bit lazy after finishing the repackaging in j-s-5, and thought I would do it the next day :-D I don't think it is lazy to put this off. Instead, I think we are all trying to tackle higher priority issues first. Speaking of higher priority issues, I would vote for resolving the getHeaders() problem since they are causing Watchdog failures. Are you and Costin comfortable with Steve Downey's latest proposal (headers are split on , for only the headers explicitly defined in the HTTP/1.1 specification)? Patrick -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: VOTE: Restoring Tomcat examples: Which workspace?
Patrick Luby wrote: Remy, Remy Maucherat wrote: I just got a bit lazy after finishing the repackaging in j-s-5, and thought I would do it the next day :-D I don't think it is lazy to put this off. Instead, I think we are all trying to tackle higher priority issues first. Speaking of higher priority issues, I would vote for resolving the getHeaders() problem since they are causing Watchdog failures. Are you and Costin comfortable with Steve Downey's latest proposal (headers are split on , for only the headers explicitly defined in the HTTP/1.1 specification)? No, doing that for getHeaders would cause problems, as pointed out by Costin. I'm not convinced anymore the test is valid at all, after reading Costin's arguments. Strong -1 on changing the behavior of getHeader, but I could be talked into implementing comma-parsing for getHeaders if you can prove Costin was wrong. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Headers
On Tue, 20 Aug 2002, Patrick Luby wrote: Are you and Costin comfortable with Steve Downey's latest proposal (headers are split on , for only the headers explicitly defined in the HTTP/1.1 specification)? I am not. I am ok ( and I think it is required ) to merge all headers with the same name, but not to split. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: VOTE: Restoring Tomcat examples: Which workspace?
Regarding examples/: One think I would like to see is removal of all webapp-related config from server.xml, and moving it to webapps/examples.xml ( there is already code to support it ). Not sure how it would work with the current jmx code ( the saving part), but hopefully that will be replaced with the jndi stuff and it will be even easier this way. A second issue is related with the startup order/sequence. I'll send a separate proposal with the details - I don't expect it to be implemented very soon and is not a big priority, but nice to have before releasing and nice to have agreement on it before. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: VOTE: Restoring Tomcat examples: Which workspace? NEW?
On August 20, 2002 11:42 am, you wrote: The examples are portable and independent of Tomcat, so I want them to go into jakarta-servletapi-5. I posted some time ago about that, and I was planning to do it. Maybe a separate cvs repo? jakarta-servlet-examples? Before I started getting involved I never bothered to download the servlet-api download because I knew the container would provide something I could compile against. Maybe they would not be as visible if packaged inside servlet-api? At the very least it should be built as a separate self-contained examples.war file that can just be auto-deployed in any compliant container. Ian -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
broken locking in StandardWrapper.allocate()
In StandardWrapper.java lines 651 through 664 of Tomcat 4.0.4, the double-check locking idiom is used to avoid synchronization. The double-check locking idiom does not work reliably in Java. For reasons why, see: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html The result of using the current code is that requests can be processed (the servlet's service method can be called) before the servlet's init method has completed and/or before values written in init are visible to other threads that are running the service method. To fix, take out the outermost if statement. That is, remove if (instance == null) { ... } but keep the code inside the if statement as is. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5] Proposal: webapp startup
There are several possible use cases, and I think we should try to provide options to support each one. Regardless of the startup timing, in all cases no request will be served from an webapp until all initialization is done, including load on startup servlets. There are 2 options here: 1. Wait. The request will be delayed until the initialization completes. The user will just see a slow request. 2. 503. A response page with 'application is temporarily unavilable' or 'starting' or 'refreshing' - eventually with a meta reload. There are several options for how to load: 1. load-on-startup, serial ( maybe with ordering). That's the current situation. All webapps declared in server.xml are loaded in the defined order - and if we move to separate .xmls for each webapp in webapps, we can add an 'sequence' option and require it to be loaded sequencialy and before the server port is started. 2. load-on-startup, parallel. That's very usefull if we have many applications and will speed up the startup. The server port will begin accepting connections after all apps with load-on-startup are loaded. 3. load-on-startup, delayed. For some applications it may be usefull to not delay the start of the server - the startup will be done in background and no request for it will be served until the app is ready. 4. load-on-demand. The context will be initialized when the first request for that context is received. That is the only reasonable choice if you have many ( 50+ ? ) small webapps ( say a hosting env ). I don't see this as a big priority, but nice to have. I'll implement the 'load-on-startup, parallel' as soon as I figure how to do the thread binding and find the time. For example, the admin/ app can be very well loaded on demand or delayed - and same for any app that is not 'critical'. It is far better to have tomcat restart quickly and have minimal downtime for the frequently used apps ( where load-on-startup is a good choice ), and use delayed for less-frequent or less critical apps. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] Proposal: webapp startup
[EMAIL PROTECTED] wrote: There are several possible use cases, and I think we should try to provide options to support each one. Regardless of the startup timing, in all cases no request will be served from an webapp until all initialization is done, including load on startup servlets. There are 2 options here: 1. Wait. The request will be delayed until the initialization completes. The user will just see a slow request. 2. 503. A response page with 'application is temporarily unavilable' or 'starting' or 'refreshing' - eventually with a meta reload. There are several options for how to load: 1. load-on-startup, serial ( maybe with ordering). That's the current situation. All webapps declared in server.xml are loaded in the defined order - and if we move to separate .xmls for each webapp in webapps, we can add an 'sequence' option and require it to be loaded sequencialy and before the server port is started. 2. load-on-startup, parallel. That's very usefull if we have many applications and will speed up the startup. The server port will begin accepting connections after all apps with load-on-startup are loaded. 3. load-on-startup, delayed. For some applications it may be usefull to not delay the start of the server - the startup will be done in background and no request for it will be served until the app is ready. 4. load-on-demand. The context will be initialized when the first request for that context is received. That is the only reasonable choice if you have many ( 50+ ? ) small webapps ( say a hosting env ). I don't see this as a big priority, but nice to have. I'll implement the 'load-on-startup, parallel' as soon as I figure how to do the thread binding and find the time. For example, the admin/ app can be very well loaded on demand or delayed - and same for any app that is not 'critical'. Actually, implementing the xml validation on/off mechanism, admin/ is _the_ reason why Tomcat is slow at startup. There is a lot of xml files to parse/validate in that applicationso I'm +1 to load on demand and set validation to false :-) I know it may involve a lot of work, but It might be nice to have an option in server.xml that configure the web-app startup mode? -- Jeanfrancois It is far better to have tomcat restart quickly and have minimal downtime for the frequently used apps ( where load-on-startup is a good choice ), and use delayed for less-frequent or less critical apps. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11867] New: - Default Context in TC 4.0.4-B3
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=11867. 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=11867 Default Context in TC 4.0.4-B3 Summary: Default Context in TC 4.0.4-B3 Product: Tomcat 4 Version: 4.0.4 Beta 3 Platform: PC OS/Version: Other Status: UNCONFIRMED Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello: I am trying to turn off cookies for an application that I have deployed automatically. To do that, I uncommented the Context tag in the server.xml that had a path attribute with an empty string. I then added cookies=false and restarted my application. Unfortunately, my simple JSP test (that shows sessions) indicated that it was reusing an existing session (instead of creating a new one each time). My JSP was not rewriting the URL, so that's not what I expected. If I put this test JSP page into the examples context and set cookies=false for that context, the application worked properly. I wasn't sure whether the default context was properly being handled for 4.0.4- B3 or an explicit DefaultContext tag is needed for this to work. Your documentation seems to indicate both options. Thanks, Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] Proposal: webapp startup
Jean-francois Arcand wrote: [EMAIL PROTECTED] wrote: There are several possible use cases, and I think we should try to provide options to support each one. Regardless of the startup timing, in all cases no request will be served from an webapp until all initialization is done, including load on startup servlets. There are 2 options here: 1. Wait. The request will be delayed until the initialization completes. The user will just see a slow request. 2. 503. A response page with 'application is temporarily unavilable' or 'starting' or 'refreshing' - eventually with a meta reload. There are several options for how to load: 1. load-on-startup, serial ( maybe with ordering). That's the current situation. All webapps declared in server.xml are loaded in the defined order - and if we move to separate .xmls for each webapp in webapps, we can add an 'sequence' option and require it to be loaded sequencialy and before the server port is started. 2. load-on-startup, parallel. That's very usefull if we have many applications and will speed up the startup. The server port will begin accepting connections after all apps with load-on-startup are loaded. 3. load-on-startup, delayed. For some applications it may be usefull to not delay the start of the server - the startup will be done in background and no request for it will be served until the app is ready. 4. load-on-demand. The context will be initialized when the first request for that context is received. That is the only reasonable choice if you have many ( 50+ ? ) small webapps ( say a hosting env ). I don't see this as a big priority, but nice to have. I'll implement the 'load-on-startup, parallel' as soon as I figure how to do the thread binding and find the time. For example, the admin/ app can be very well loaded on demand or delayed - and same for any app that is not 'critical'. Actually, implementing the xml validation on/off mechanism, admin/ is _the_ reason why Tomcat is slow at startup. I know, at it is the only major difference between TC 4.0 and 4.1 in the startup time. The new Beanutils 1.4.1 also fixes a performance bug which could help things big time (and right on time before the 4.1 release). There is a lot of xml files to parse/validate in that applicationso I'm +1 to load on demand and set validation to false :-) Cool :) I'm sooo tempted to try to port that for 4.1.10, but this is bad as it greatly affects the behavior of Tomcat. Maybe it would be best to leave it for a major release. Or it could be ported, by we'd have to default to always validate. I know it may involve a lot of work, but It might be nice to have an option in server.xml that configure the web-app startup mode? Implementing them all would be painful IMO ;-) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] Proposal: webapp startup
On Tue, Aug 20, 2002 at 09:59:11AM -0700, [EMAIL PROTECTED] wrote: There are several possible use cases, and I think we should try to provide options to support each one. Agreed. Regardless of the startup timing, in all cases no request will be served from an webapp until all initialization is done, including load on startup servlets. There are 2 options here: 1. Wait. The request will be delayed until the initialization completes. The user will just see a slow request. 2. 503. A response page with 'application is temporarily unavilable' or 'starting' or 'refreshing' - eventually with a meta reload. Options are good, but I vote for wait to be the default behavior. (Supporting use cases are below.) There is a third option, by the way: 3. Wait with timeout. The request is queued, but if it takes longer than a specified time to process (say, 20 seconds), then it returns a 503. The third case actually subsumes the first two, since case 1 is enabled by setting the timeout very high, and case 2 is enabled by setting it very low (like 0). So I think this might be the best design choice: only one algorithm to implement, only one setting to configure. If I wanted to make a patch proposal, what source file(s) should I look at? It's been a while... --- Why I think Wait should be the default: Use cases: * Human UI: most naive users will tolerate a pause (of up to, say, 30 seconds) much better than they will understand that the proper response to a 503 is to wait a moment and then click reload. Instead, they will think this site is down and go to your competitor's :-) * Scripts: my test scripts launch Tomcat, then send a bunch of test requests and verify the results. A 503 will cause the tests to fail (unless I write special code to handle that case). Behavior seems to be mixed now -- there's a window where requests will fail, following which they will wait. There's also a condition where a request at just the wrong time will corrupt the webapp, causing all future requests to fail, but since I haven't been able to reproduce it I haven't reported it. -- Alex Chaffee mailto:[EMAIL PROTECTED] jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] Proposal: webapp startup
On Tue, 20 Aug 2002, Jean-francois Arcand wrote: Actually, implementing the xml validation on/off mechanism, admin/ is _the_ reason why Tomcat is slow at startup. There is a lot of xml files to parse/validate in that applicationso I'm +1 to load on demand and set validation to false :-) It's not _the_ reason, just one of the reasons. Try taking off the jmx listeners - you'll see a difference. I'll start commiting ( really soon :-) the common-logging changes, and one thing I added in various places is logging the time it takes to do various operations ( if it's 200 ms ). I think I get most of the 'suspects' accounted for. I already mentioned that for me the 'minimal' tomcat5 starts in 6 seconds - all the extra stuff can be put in background. Costin I know it may involve a lot of work, but It might be nice to have an option in server.xml that configure the web-app startup mode? -- Jeanfrancois It is far better to have tomcat restart quickly and have minimal downtime for the frequently used apps ( where load-on-startup is a good choice ), and use delayed for less-frequent or less critical apps. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] Proposal: webapp startup
On Tue, 20 Aug 2002, Alex Chaffee / Purple Technology wrote: There is a third option, by the way: 3. Wait with timeout. The request is queued, but if it takes longer than a specified time to process (say, 20 seconds), then it returns a 503. Probably that's the best - and should be the only 'option'. The third case actually subsumes the first two, since case 1 is enabled by setting the timeout very high, and case 2 is enabled by setting it very low (like 0). So I think this might be the best design choice: only one algorithm to implement, only one setting to configure. +1 If I wanted to make a patch proposal, what source file(s) should I look at? It's been a while... I'm not sure - I'm still confused by the dozens of interfaces/base classes/etc. Hopefully coyote and the jndi config will simplify that. The critical issue is making the context init work in another thread - I tried putting the webapp initialization in a separate thread but can't figure the context binding. And I tried a lot of tricks... If Remy can do that... What I did is make ContextConfig implement Runnable, rename start() to run() and added a start() method with: new Thread(this).start(); However I can't get it to find web.xml and anything else. I tried bindThread - but doesn't seem to work. Why I think Wait should be the default: Use cases: * Human UI: most naive users will tolerate a pause (of up to, say, 30 seconds) much better than they will understand that the proper response to a 503 is to wait a moment and then click reload. Instead, they will think this site is down and go to your competitor's :-) That's a matter of taste. I would rather see a page saying 'the app is starting, it'll be ready in few minutes' - or a smart guy could tune this and add some intermediary screen, maybe some javascript progress bar. Waiting 30 seconds is not a good impression. And the current alternative is not beeing able to connect to the site ( since the server is down ). Much worse... The 503 can also be used by lb to go to a different instance. * Scripts: my test scripts launch Tomcat, then send a bunch of test requests and verify the results. A 503 will cause the tests to fail (unless I write special code to handle that case). I agree with this one. Probably configurable is the best choice, and until that the 'wait' behavior is better. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11868] New: - The Tomcat service terminated unexpectedly
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=11868. 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=11868 The Tomcat service terminated unexpectedly Summary: The Tomcat service terminated unexpectedly Product: Tomcat 4 Version: 4.0.4 Final Platform: Other OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The Tomcat (ver 4.0) service runs normally as long as I am logged in on the Windows 2000 server. As soon as I log off the windows 2000 server the tomcat service goes down. I see a message in the Eventlog that the service has terminated unexpectedly! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Errata: Rebo instead of Rebi
Sorry, Joe, Typo on Teresa's name fixed here. Micael business_card.doc Description: MS-Word document -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH][Catalina] Validation turned off by default.
Hi, attached is a patch that implement the mechanism to turn off/on the XML validation and namespace awareness. Starting with this patch, validation/namespace will be turned off. If you want to turn it on, do: Host name=localhost debug=0 appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=true xmlNamespaceAware=true *xmlValidation and xmlNamespaceAware are optional attributes. Current server.xml file are still supported. I did not implement the functionality for server.xml and user.xml since the validation was turned off by default (and willnot work if validation is turned on). Thanks, -- Jeanfrancois Index: server.xml === RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/conf/server.xml,v retrieving revision 1.3 diff -u -r1.3 server.xml --- server.xml 4 Aug 2002 19:41:06 - 1.3 +++ server.xml 20 Aug 2002 18:25:01 - @@ -219,10 +219,19 @@ userRoleTable=user_roles roleNameCol=role_name / -- - !-- Define the default virtual host -- - Host name=localhost debug=0 appBase=webapps + !-- Define the default virtual host.-- + !--Host name=localhost debug=0 appBase=webapps unpackWARs=true autoDeploy=true + -- + !-- Define the default virtual host. Uncomment this element if you + want to turn on XML schema/dtd validation. -- + + Host name=localhost debug=0 appBase=webapps +unpackWARs=true autoDeploy=true +xmlValidation=true xmlNamespaceAware=true + + !-- Normally, users must authenticate themselves to each web app individually. Uncomment the following entry if you would like a user to be authenticated the first time they encounter a Index: Host.java === RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Host.java,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 Host.java --- Host.java 18 Jul 2002 16:47:37 - 1.1.1.1 +++ Host.java 20 Aug 2002 18:17:57 - @@ -171,8 +171,39 @@ * @exception IllegalArgumentException if name is null */ public void setName(String name); + + +/** + * Get the server.xml host attribute's xmlNamespaceAware. + * @return true if namespace awarenes is enabled. + * + */ +public boolean getXmlNamespaceAware(); + + +/** + * Get the server.xml host attribute's xmlValidation. + * @return true if validation is enabled. + * + */ +public boolean getXmlValidation(); - + +/** + * Set the validation feature of the XML parser used when + * parsing xml instances. + * @param xmlValidation true to enable xml instance validation + */ +public void setXmlValidation(boolean xmlValidation); + + + /** + * Set the namespace aware feature of the XML parser used when + * parsing xml instances. + * @param xmlNamespaceAware true to enable namespace awareness + */ +public void setXmlNamespaceAware(boolean xmlNamespaceAware); + // - Public Methods Index: StandardHost.java === RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHost.java,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 StandardHost.java --- StandardHost.java 18 Jul 2002 16:48:08 - 1.1.1.1 +++ StandardHost.java 20 Aug 2002 18:18:35 - @@ -211,7 +211,20 @@ * DefaultContext config */ private DefaultContext defaultContext; - + + +/** + * Attribute value used to turn on/off XML validation + */ + private boolean xmlValidation = false; + + +/** + * Attribute value used to turn on/off XML namespace awarenes. + */ + private boolean xmlNamespaceAware = false; + + // - Properties @@ -519,8 +532,48 @@ this.workDir = workDir; } - - + + + /** + * Set the validation feature of the XML parser used when + * parsing xml instances. + * @param xmlValidation true to enable xml instance validation + */ +public void setXmlValidation(boolean xmlValidation){ +this.xmlValidation = xmlValidation; +} + + +/** + * Get the server.xml host attribute's xmlValidation. + * @return true if validation is enabled. + * + */ +public boolean getXmlValidation(){ +return xmlValidation; +} + + +/** + * Get the server.xml host attribute's xmlNamespaceAware. + * @return true if namespace awarenes is enabled. + * + */ +public boolean getXmlNamespaceAware(){ +
cvs commit: jakarta-tomcat-5 build2.xml
costin 2002/08/20 12:02:40 Modified:.build2.xml Log: Update the paths for servletapi. rename 'checkout' to update. Add discovery and a small test for it. Revision ChangesPath 1.5 +44 -15jakarta-tomcat-5/build2.xml Index: build2.xml === RCS file: /home/cvs/jakarta-tomcat-5/build2.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- build2.xml10 Aug 2002 16:32:10 - 1.4 +++ build2.xml20 Aug 2002 19:02:40 - 1.5 @@ -10,8 +10,8 @@ property file=build.properties/ property file=build.properties.default/ - property name=basedir location=. / - + property name=basedir location=./ + !-- Source dependencies -- property name=api.home value=${basedir}/../jakarta-servletapi-5/ @@ -31,7 +31,8 @@ property name=build.dir value=${basedir}/build/ property name=log4j.jar value=${base.path}/log4j/log4j.jar/ - + + path id=alljars pathelement location=${jmx.jar}/ @@ -95,6 +96,7 @@ path location=${commons.home}/collections/src/java / path location=${commons.home}/beanutils/src/java / path location=${commons.home}/logging/src/java / +path location=${commons.home}/discovery/src/java / /src exclude name=org/apache/tomcat/util/net/PureTLS* / exclude name=org/apache/commons/logging/impl/LogKitLogger.java / @@ -103,6 +105,9 @@ !-- Fail with GCJ -- exclude name=org/apache/commons/collections/DoubleOrderedMap.java / exclude name=org/apache/tomcat/util/log/CommonLogHandler.java / + + exclude name=org/apache/commons/discovery/D** / + exclude name=org/apache/commons/discovery/*/** / /javac copy toDir=${build.dir}/classes fileset dir=${commons.home}/modeler/src/java @@ -128,7 +133,8 @@ debug=on classpathref=alljars src -path location=${api.home}/src/share / +path location=${api.home}/jsr152/src/share / +path location=${api.home}/jsr154/src/share / path location=${catalina.home}/catalina/src/share / path location=${jtc.home}/coyote/src/java / path location=${jtc.home}/jk/java / @@ -161,24 +167,25 @@ /copy copy toDir=${build.dir}/classes -fileset dir=${api.home}/src/share +fileset dir=${api.home}/jsr154/src/share + include name=**/*.properties/ +/fileset +fileset dir=${api.home}/jsr152/src/share include name=**/*.properties/ /fileset /copy !-- Servlet/JSP resources - work around stupid src layout -- copy todir=${build.dir}/classes/javax/servlet/resources -fileset dir=${api.home}/src/share/dtd - include name=web-app**/ - include name=j2ee*.xsd/ - include name=xml.xsd/ +fileset dir=${api.home}/jsr154/src/share/dtd + include name=*.xsd/ + include name=*.dtd/ /fileset /copy copy todir=${build.dir}/classes/javax/servlet/jsp/resources - fileset dir=${api.home}/src/share/dtd -include name=web-jsptaglibrary**/ -include name=jspxml**/ -include name=jsp*.xsd/ + fileset dir=${api.home}/jsr152/src/share/dtd +include name=*.xsd/ +include name=*.dtd/ /fileset /copy /target @@ -252,8 +259,9 @@ path refid=alljars / path refid=jasperjars / pathelement location=${build.dir}/classes/ - pathelement location=${ant.home}/lib/xercesImpl.jar / + !-- pathelement location=${ant.home}/lib/xercesImpl.jar / pathelement location=${ant.home}/lib/xml-apis.jar / + -- pathelement location=${ant.home}/lib/ant.jar / pathelement location=${tools.jar} / /path @@ -273,6 +281,27 @@ echo message= Tomcat5 up and running / /target + target name=discovery +path id=discoveryCP + path refid=alljars/ + path refid=jasperjars/ + pathelement location=${build.dir}/classes/ + pathelement location=${ant.home}/lib/xercesImpl.jar/ + pathelement location=${ant.home}/lib/xml-apis.jar/ + pathelement location=${ant.home}/lib/ant.jar/ + pathelement location=${tools.jar}/ + pathelement location=/usr/share/java/xalan-j_2_3_1/bin/xercesImpl.jar/ + /path + +taskdef name=discovery + classname=org.apache.commons.discovery.ServiceDiscoveryTask + classpathref=discoveryCP/ + +discovery debug=1 id=myDiscovery + serviceName=javax.xml.parsers.SAXParserFactory / +echo message=Found
DO NOT REPLY [Bug 11871] New: - Tomcat can not load context with directory
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=11871. 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=11871 Tomcat can not load context with directory Summary: Tomcat can not load context with directory Product: Tomcat 5 Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When start Tomcat 5.0, the container can not load the webapplication as a directory format (not war). The application works in Tomcat 4. 2002-08-20 12:00:07 StandardContext[/workflow]: Error initializing resources: Document base /workflow does not exist or is not a readable directory 2002-08-20 12:00:07 StandardContext[/workflow]: Context startup failed due to previous errors 2002-08-20 12:00:07 StandardContext[/workflow]: Exception during cleanup after start failed LifecycleException: Container StandardContext[/workflow] has not been started at org.apache.catalina.core.StandardContext.stop(StandardContext.java:3576) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3554) 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:2234) at org.apache.catalina.startup.Catalina.start(Catalina.java:516) at org.apache.catalina.startup.Catalina.execute(Catalina.java:402) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:20 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11740] - Errors on startup during tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11740. 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=11740 Errors on startup during tomcat [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2 build.xml
costin 2002/08/20 12:25:11 Modified:jasper2 build.xml Log: User properties must be first - that's where he can override settings. Also read the build.properties.samples - if the user has all his overrides in home, there is no need to copy it. Revision ChangesPath 1.16 +3 -1 jakarta-tomcat-jasper/jasper2/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/build.xml,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- build.xml 13 Aug 2002 16:26:45 - 1.15 +++ build.xml 20 Aug 2002 19:25:11 - 1.16 @@ -5,9 +5,10 @@ !-- See build.properties.sample in the top level directory for all -- !-- property values you must customize for successful building!!!-- + property file=${user.home}/build.properties/ property file=build.properties/ + property file=build.properties.sample/ property file=${catalina.home}/build.properties/ - property file=${user.home}/build.properties/ !-- Build Defaults -- property name=jasper.build value=${basedir}/build/ @@ -33,6 +34,7 @@ pathelement location=${xercesImpl.jar}/ pathelement location=${xmlParserAPIs.jar}/ pathelement location=${commons-collections.jar}/ +pathelement location=${commons-logging.jar}/ pathelement location=${commons-daemon-launcher.jar}/ pathelement location=${jasper.build}/shared/classes/ pathelement location=${jsp20el.jar}/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper gump2.xml
costin 2002/08/20 12:29:09 Modified:.gump2.xml Log: Add commons-logging as dependency. Revision ChangesPath 1.2 +1 -0 jakarta-tomcat-jasper/gump2.xml Index: gump2.xml === RCS file: /home/cvs/jakarta-tomcat-jasper/gump2.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- gump2.xml 31 Jul 2002 05:19:30 - 1.1 +++ gump2.xml 20 Aug 2002 19:29:09 - 1.2 @@ -10,4 +10,5 @@ home nested=jasper2/ /project + depend project=commons-logging/ /module -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspCompilationContext.java
costin 2002/08/20 12:30:29 Modified:jasper2/src/share/org/apache/jasper JspCompilationContext.java Log: Add a stack trace. This should help debug the ant test failures. Revision ChangesPath 1.16 +4 -3 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java Index: JspCompilationContext.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- JspCompilationContext.java6 Aug 2002 00:11:36 - 1.15 +++ JspCompilationContext.java20 Aug 2002 19:30:29 - 1.16 @@ -528,6 +528,7 @@ } catch (JasperException ex) { throw ex; } catch (Exception ex) { +ex.printStackTrace(); throw new JasperException( Constants.getString(jsp.error.unable.compile),ex); } -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Compiler.java
costin 2002/08/20 12:35:25 Modified:jasper2/src/share/org/apache/jasper/compiler Compiler.java Log: Switch to commons-logging instead of jasper's own logging. To enable debugging - use log4j.properties or the jdk1.4 config. Right now it uses the 'class name' convention - i.e. the name of the logger where you can enable debug is the class name. We could use a single logger for all jasper. I also added code to log the translation and compilation times - if they are more than 500ms. It can be removed before release ( or made configurable ), but for now it's good to know. Revision ChangesPath 1.29 +37 -12 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java Index: Compiler.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java,v retrieving revision 1.28 retrieving revision 1.29 diff -u -r1.28 -r1.29 --- Compiler.java 20 Aug 2002 03:52:18 - 1.28 +++ Compiler.java 20 Aug 2002 19:35:24 - 1.29 @@ -1,7 +1,4 @@ /* - * $Header$ - * $Revision$ - * $Date$ * * * @@ -98,7 +95,8 @@ * @author Mark Roth */ public class Compiler { - +private static org.apache.commons.logging.Log log= +org.apache.commons.logging.LogFactory.getLog( Compiler.class ); // - Static @@ -158,10 +156,14 @@ } else { bl.setMessageOutputLevel( Project.MSG_INFO ); } +if( log.isTraceEnabled() ) { +bl.setMessageOutputLevel( Project.MSG_VERBOSE ); +} project.addBuildListener( bl ); if( options.getCompiler() != null ) { -Constants.jasperLog.log(Compiler + options.getCompiler(), Logger.ERROR ); +if( log.isDebugEnabled() ) +log.debug(Compiler + options.getCompiler() ); project.setProperty(build.compiler, options.getCompiler() ); } project.init(); @@ -175,12 +177,13 @@ } static class JasperAntLogger extends DefaultLogger { +private static org.apache.commons.logging.Log log= +org.apache.commons.logging.LogFactory.getLog( Compiler.class ); protected void printMessage(final String message, final PrintStream stream, final int priority) { -Constants.jasperLog.log( message, Logger.INFORMATION ); +log.info( message ); } - } // - Public Methods @@ -192,6 +195,7 @@ public void generateJava() throws FileNotFoundException, JasperException, Exception { +long t1=System.currentTimeMillis(); // Setup page info area pageInfo = new PageInfo(new BeanRepository(ctxt.getClassLoader())); JspConfig jspConfig = options.getJspConfig(); @@ -255,6 +259,7 @@ // Validate and process attributes Validator.validate(this, pageNodes); +long t2=System.currentTimeMillis(); // Dump out the page (for debugging) // Dumper.dump(pageNodes); @@ -265,6 +270,8 @@ // this compilation unit. TagFileProcessor.loadTagFiles(this, pageNodes); +long t3=System.currentTimeMillis(); + // Determine which custom tag needs to declare which scripting vars ScriptingVariabler.set(pageNodes); @@ -272,6 +279,12 @@ Generator.generate(writer, this, pageNodes); writer.close(); +long t4=System.currentTimeMillis(); +if( t4-t1 500 ) { +log.info(Generated + javaFileName + total= + + (t4-t1) + generate= + ( t4-t3 ) + validate= + ( t2-t1 )); +} + //JSR45 Support - note this needs to be checked by a JSR45 guru SmapUtil.generateSmap(ctxt, pageNodes, true); } @@ -282,6 +295,7 @@ public void generateClass() throws FileNotFoundException, JasperException, Exception { +long t1=System.currentTimeMillis(); String javaEncoding = UTF8; String javaFileName = ctxt.getServletJavaFileName(); String classpath = ctxt.getClassPath(); @@ -303,6 +317,10 @@ path.setPath(System.getProperty(java.class.path) + sep + classpath); +if( log.isDebugEnabled() ) +log.debug( Using classpath: + System.getProperty(java.class.path) + sep + + classpath); + // Initializing sourcepath Path srcPath
DO NOT REPLY [Bug 11868] - The Tomcat service terminated unexpectedly
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=11868. 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=11868 The Tomcat service terminated unexpectedly [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-08-20 19:37 --- 4.0.3, 4.0.4 LE and 4.1.x have all run fine as a service, when installed with the EXE distribution. you may have a permissions issue or services account issue. By default, the installer sets the service to use the system account. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11846] - Class loader problem
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=11846. 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=11846 Class loader problem --- Additional Comments From [EMAIL PROTECTED] 2002-08-20 20:53 --- We are experiencing a very similar problem with our project. We have a Web App which is accessing EJBs running on a WebLogic 6.1 installation. Thus in WEB-INF/lib we have weblogic.jar. This works correctly using Tomcat 4.0.1. However, if we upgrade Tomcat to either 4.0.3 (as supplied with JBuilder 7) or Tomcat 4.0.4 when we receive: java.lang.NoClassDefFoundError: javax/ejb/EJBException at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:486) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1643) at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:937) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1372) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1254) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) (you get the idea...) I haven't managed to get manager approval for time to produce a test case unfortunately :-( Will keep trying. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] Proposal: webapp startup
Aha ! I think I got it, it has nothing to do with the naming... When I do a start() and try to do the config in the background, the 'ok' return status is not set and the main thread believe an error happened and resets the resource field. Costin On Tue, 20 Aug 2002 [EMAIL PROTECTED] wrote: On Tue, 20 Aug 2002, Alex Chaffee / Purple Technology wrote: There is a third option, by the way: 3. Wait with timeout. The request is queued, but if it takes longer than a specified time to process (say, 20 seconds), then it returns a 503. Probably that's the best - and should be the only 'option'. The third case actually subsumes the first two, since case 1 is enabled by setting the timeout very high, and case 2 is enabled by setting it very low (like 0). So I think this might be the best design choice: only one algorithm to implement, only one setting to configure. +1 If I wanted to make a patch proposal, what source file(s) should I look at? It's been a while... I'm not sure - I'm still confused by the dozens of interfaces/base classes/etc. Hopefully coyote and the jndi config will simplify that. The critical issue is making the context init work in another thread - I tried putting the webapp initialization in a separate thread but can't figure the context binding. And I tried a lot of tricks... If Remy can do that... What I did is make ContextConfig implement Runnable, rename start() to run() and added a start() method with: new Thread(this).start(); However I can't get it to find web.xml and anything else. I tried bindThread - but doesn't seem to work. Why I think Wait should be the default: Use cases: * Human UI: most naive users will tolerate a pause (of up to, say, 30 seconds) much better than they will understand that the proper response to a 503 is to wait a moment and then click reload. Instead, they will think this site is down and go to your competitor's :-) That's a matter of taste. I would rather see a page saying 'the app is starting, it'll be ready in few minutes' - or a smart guy could tune this and add some intermediary screen, maybe some javascript progress bar. Waiting 30 seconds is not a good impression. And the current alternative is not beeing able to connect to the site ( since the server is down ). Much worse... The 503 can also be used by lb to go to a different instance. * Scripts: my test scripts launch Tomcat, then send a bunch of test requests and verify the results. A 503 will cause the tests to fail (unless I write special code to handle that case). I agree with this one. Probably configurable is the best choice, and until that the 'wait' behavior is better. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext TagLibraryInfo.java
kinman 2002/08/20 14:08:24 Modified:jsr152/src/share/javax/servlet/jsp/tagext TagLibraryInfo.java Log: - Removed annoying No tags messages, now that either a tag or/and tagfile can be in a tag library. Revision ChangesPath 1.3 +0 -2 jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/TagLibraryInfo.java Index: TagLibraryInfo.java === RCS file: /home/cvs/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/TagLibraryInfo.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- TagLibraryInfo.java 19 Aug 2002 16:29:51 - 1.2 +++ TagLibraryInfo.java 20 Aug 2002 21:08:24 - 1.3 @@ -224,7 +224,6 @@ TagInfo tags[] = getTags(); if (tags == null || tags.length == 0) { -System.err.println(No tags); return null; } @@ -248,7 +247,6 @@ TagFileInfo tagFiles[] = getTagFiles(); if (tagFiles == null || tagFiles.length == 0) { -System.err.println(No tags); return null; } -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11875] New: - AuthenticatorBase accessControl call makes unnecessary allocations
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=11875. 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=11875 AuthenticatorBase accessControl call makes unnecessary allocations Summary: AuthenticatorBase accessControl call makes unnecessary allocations Product: Tomcat 4 Version: 4.0.4 Final Platform: All OS/Version: Other Status: UNCONFIRMED Severity: Minor Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] In the function accessControl(), in the block that checks each role to see if it's included in the constraint, there no need to get the realm, call findAuthRoles() or allocate a new String[] for 'roles' _if_ constraint.getAllRoles() is true. If users declare '*' as the security constraint or declares no security constraint (e.g. no access), these calls are made on every request. Fixes: - move test of getAllRoles() above the other calls. - move call to getRealm() to just above the 'for' loop where it's used. Per -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Strange delays while Tomcat works
Thanks for the suggestion, however: We are running on a dual Athlon 1900/1GB RAM/2x18Gb 15K RPM SCSI FreeBSD system, yet the processor load hits 100% (top). We have tried running the same on Resin, and DO NOT have the problem... It seems to be some internal Tomcat bug. How and what can we test/report to diagnose and fix the problem? We WANT to fix the problem ourselves, but it would help to know where to dig... Many thanks in advanvce! Dev Zero G team Mladen Turk wrote: -Original Message- From: Dev Zero G Ltd [mailto:[EMAIL PROTECTED]] Sent: Monday, August 19, 2002 9:31 PM To: Tomcat Developers List Subject: Strange delays while Tomcat works If your processor load is low during those delays then it seems to me that you have a problems like a network name to IP resolvings. Try to eliminate all the 'named' resources to IP based. we have) - for aproximately 5-6 seconds, and processes JSP page. The very strange behavior aoccurs right there - custom tags may be executed for 2,3,6 or even 10 seconds. In other time, after executing part of JSP page, debug output stops, and continues after 2-3 seconds. -- 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]
Tomcat 4.0.4 / Apache 2 connector (mod_jk2.so jk_jni.so)
Hello and thanks for reading. Building and then launching the Tomcat 4.0.4 connector for Apache 2 on FreeBSD 4.4, linux-jdk 1.4 , we get: org.apache.jk.server.JkMain init INFO: Starting Jk2, base dir= /usr/local/tomcat4.0.4_1.4.0 conf=/usr/local/tomcat4.0.4_1.4.0/conf/jk2.properties org.apache.jk.server.JkMain start INFO: APR not loaded, disabling jni components: java.io.IOException: /usr/local/ tomcat4.0.4_1.4.0/lib/jk_jnicb.so: /usr/local/tomcat4.0.4_1.4.0/lib/jk_jni.so: ELF file OS ABI invalid. Then, we were answered: I'm assuming you're running 1.4 under Linux emulation, since the native 1.4 isn't near finished yet :). The obvious guess would then be that the shared library jk_jni.so is in fact a native FreeBSD shared library when it needs to be a Linux shared library. Any shared library loaded by a Linux JDK running under emulation must be a Linux shared library. After that we have tried to build jkjni.so with native freeBSD jdk1.3, so this shared library can use native FreeBSD methods. But, after starting Tomcat 4.0.4 (jdk 1.3) we get: Error JniHandler - -nativeDispatch: error 21000 Error ChannelUn - -receive error: 21000 (info) [jk_jni_aprImpl.c (470)] jkInvoke() invoke 2db8bd2c (info) [jk_channel_un.c (292)] channelUn.close(): close unix socket -1 (error) [jk_channel_un.c (416)] channelUn.receive():error receiving -3 9 Bad file descriptor 0x15abd0f0 -1 ANY ideas, suggestions, guesses - would be greatly appreciated. Thanks in advance. Dev Zero G Team http://devzerog.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5] UserDatabase - DirContext
If we're using JNDI for configuration, then it's a good idea to use JNDI for user config ( tomcat-users.xml ). That would make the jndi authenticator 'first class'. In order to support jdbc 'user databases' we just need a jndi-jdbc adapter. I think that's a very nice and flexible solution - and will greatly simplify our code ( i.e. less depenencies ). It can also take care of the issues we have with keeping all the users in memory, and we can adapt the jndi cache for users ( which would be very cool !) It also means that in order to plug a new user database into tomcat you only need to implement a (standard) jndi DirContext. If you agree with that, we can( should ) eventually deprecate the actual intefaces ( UserDatabase, User, etc ), and document that a 'user database' is just a Context, and the user is just a DirContext with a number of required attributes. ( eventually named based on the ldap schema - inetPerson? , for maximum transparency ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: build err on tc 4.1.9
Henri Gomez wrote: I've got the following error when building TC 4.1.9 build-main: [javac] Compiling 161 source files to /usr/src/redhat/BUILD/tomcat4-4.1.9/jakarta-tomcat-4.1.9-src/webapps/build/admin/WEB-INF/classes [javac] Found 2 semantic errors compiling /usr/src/redhat/BUILD/tomcat4-4.1.9/jakarta-tomcat-4.1.9-src/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TomcatTreeBuilder.java: [javac]128. mBServer = servlet.getServer(); [javac]--- [javac] *** Error: You need to modify your classpath, sourcepath, bootclasspath, and/or extdirs setup. Package javax/sql could not be found in: [javac] /opt/IBMJava2-131/jre/lib/ext/ibmjcaprovider.jar [javac] /opt/IBMJava2-131/jre/lib/ext/jaas.jar [javac] /opt/IBMJava2-131/jre/lib/ext/jaas_lm.jar [javac] /opt/IBMJava2-131/jre/lib/ext/comm.jar [javac] /opt/IBMJava2-131/jre/lib/ext/indicim.jar [javac] /usr/src/redhat/BUILD/tomcat4-4.1.9/jakarta-tomcat-4.1.9-src/webapps/build/admin/WEB-INF/classes [javac] /usr/share/java/commons-modeler.jar [javac] /usr/share/java/mx4j.jar [javac] /usr/share/java/servlet-2.3.jar [javac] /usr/share/java/struts.jar [javac] /usr/share/java/xml-commons-apis.jar [javac] /usr/share/java/jaxp_parser_impl.jar [javac] /usr/share/java/ant-optional.jar [javac] /usr/share/java/ant.jar [javac] /usr/share/java/xalan-j2.jar [javac] /opt/IBMJava2-131/lib/tools.jar [javac] /opt/IBMJava2-131/jre/lib/rt.jar [javac] /usr/src/redhat/BUILD/tomcat4-4.1.9/jakarta-tomcat-4.1.9-src/webapps/admin/WEB-INF/classes [javac] . [javac]128. mBServer = servlet.getServer(); [javac]--- [javac] *** Error: Type javax/sql/DataSource was not found. BUILD FAILED file:/usr/src/redhat/BUILD/tomcat4-4.1.9/jakarta-tomcat-4.1.9-src/webapps/admin/build.xml:179: Compile failed; see the compiler error output for details. Total time: 55 seconds error: Bad exit status from /var/tmp/rpm-tmp.53791 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.53791 (%build) What's the problem with javax/sql/DataSource for a MBeanServer ? There shouldn't be a problem. I don't understand why the error given the message. H. Does anyone else get this? Amy Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardHostDeployer.java StandardServer.java
amyroh 2002/08/20 16:09:18 Modified:catalina/src/share/org/apache/catalina/core StandardHostDeployer.java StandardServer.java Log: Change install(String contextPath, URL war, String configFile) method to actually save context info to the configuration file you specify. Revision ChangesPath 1.4 +11 -4 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java Index: StandardHostDeployer.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- StandardHostDeployer.java 2 Aug 2002 01:37:43 - 1.3 +++ StandardHostDeployer.java 20 Aug 2002 23:09:18 - 1.4 @@ -75,10 +75,12 @@ import org.apache.catalina.Container; import org.apache.catalina.Context; import org.apache.catalina.Deployer; +import org.apache.catalina.Engine; import org.apache.catalina.Globals; import org.apache.catalina.Lifecycle; import org.apache.catalina.LifecycleException; import org.apache.catalina.LifecycleListener; +import org.apache.catalina.core.StandardServer; import org.apache.catalina.startup.ContextRuleSet; import org.apache.catalina.startup.NamingRuleSet; import org.apache.catalina.util.StringManager; @@ -344,6 +346,11 @@ host.fireContainerEvent(PRE_INSTALL_EVENT, context); host.addChild(context); host.fireContainerEvent(INSTALL_EVENT, context); + +// save context info into configFile +Engine engine = (Engine)host.getParent(); +StandardServer server = (StandardServer) engine.getService().getServer(); +server.storeContext(context); } catch (Exception e) { host.log(sm.getString(standardHost.installError, contextPath), e); 1.5 +61 -4 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardServer.java Index: StandardServer.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardServer.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- StandardServer.java 14 Aug 2002 19:36:17 - 1.4 +++ StandardServer.java 20 Aug 2002 23:09:18 - 1.5 @@ -803,6 +803,63 @@ } +/** + * Write the configuration information for codeContext/code + * out to the specified configuration file. + * + * @exception InstanceNotFoundException if the managed resource object + * cannot be found + * @exception MBeanException if the initializer of the object throws + * an exception, or persistence is not supported + * @exception RuntimeOperationsException if an exception is reported + * by the persistence mechanism + */ +public synchronized void storeContext(Context context) throws Exception { + +String configFile = context.getConfigFile(); + +if (configFile != null) { +File config = new File(configFile); +if (!config.isAbsolute()) { +config = new File(System.getProperty(catalina.base), +configFile); +} + +// Open an output writer for the new configuration file +PrintWriter writer = null; +try { +writer = new PrintWriter(new FileWriter(config)); +} catch (IOException e) { +if (writer != null) { +try { +writer.close(); +} catch (Throwable t) { +; +} +} +throw (e); +} + +writer.print(Context); +storeAttributes(writer, context); +writer.println(/Context); + +// Flush and close the output file +try { +writer.flush(); +} catch (Exception e) { +throw (e); +} +try { +writer.close(); +} catch (Exception e) { +throw (e); +} +} + +} + + // Private Methods -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Compiler.java ParserController.java TagFileProcessor.java TagLibraryInfoImpl.java
luehe 2002/08/20 16:35:31 Modified:jasper2/src/share/org/apache/jasper JspCompilationContext.java jasper2/src/share/org/apache/jasper/servlet JspServletWrapper.java jasper2/src/share/org/apache/jasper/compiler Compiler.java ParserController.java TagFileProcessor.java TagLibraryInfoImpl.java Log: Added support for tag files packaged in JARs. Revision ChangesPath 1.17 +27 -8 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java Index: JspCompilationContext.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- JspCompilationContext.java20 Aug 2002 19:30:29 - 1.16 +++ JspCompilationContext.java20 Aug 2002 23:35:30 - 1.17 @@ -63,7 +63,7 @@ import java.io.*; import java.net.*; -import java.util.Set; +import java.util.*; import javax.servlet.ServletContext; import javax.servlet.jsp.tagext.TagInfo; @@ -89,6 +89,9 @@ */ public class JspCompilationContext { +private Hashtable tagFileJars; +private boolean isPackagedTagFile; + protected String servletClassName; protected String jspUri; private boolean isErrPage; @@ -148,6 +151,8 @@ baseURI += '/'; } this.rctxt=rctxt; + + this.tagFileJars = new Hashtable(); } public JspCompilationContext(String tagfile, @@ -155,12 +160,16 @@ Options options, ServletContext context, JspServletWrapper jsw, - JspRuntimeContext rctxt) { + JspRuntimeContext rctxt, + Hashtable tagFileJars) { this(tagfile, false, options, context, jsw, rctxt); this.isTagFile = true; this.tagInfo = tagInfo; -return; + this.tagFileJars = tagFileJars; + if (tagFileJars != null tagFileJars.get(tagfile) != null) { + isPackagedTagFile = true; + } } /* Methods to override */ @@ -268,7 +277,17 @@ } return path; } - + +/** + * Returns the tag-file-to-JAR-file mapping for tag files packaged in JARs. + * + * The mapping uses the tag file name as the key, and the JAR file + * containing the tag file as the value. + */ +public Hashtable getTagFileJars() { + return tagFileJars; +} + /* Common implementation */ /** @@ -521,7 +540,7 @@ public void compile() throws JasperException, FileNotFoundException { createCompiler(); - if (jspCompiler.isOutDated()) { + if (isPackagedTagFile || jspCompiler.isOutDated()) { try { jspCompiler.compile(); reload = true; 1.13 +7 -5 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java Index: JspServletWrapper.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- JspServletWrapper.java6 Aug 2002 00:11:36 - 1.12 +++ JspServletWrapper.java20 Aug 2002 23:35:30 - 1.13 @@ -72,6 +72,7 @@ import java.io.IOException; import java.io.FileNotFoundException; +import java.util.Hashtable; import java.net.URL; import java.net.URLClassLoader; import java.net.MalformedURLException; @@ -134,14 +135,15 @@ */ public JspServletWrapper(ServletContext servletContext, Options options, String tagFilePath, TagInfo tagInfo, - JspRuntimeContext rctxt) + JspRuntimeContext rctxt, Hashtable tagFileJars) throws JasperException { this.config = null; // not used this.options = options; this.jspUri = tagFilePath; ctxt = new JspCompilationContext(jspUri, tagInfo, options, - servletContext, this, rctxt); + servletContext, this, rctxt, + tagFileJars); // Store tag file .java and .class files in standard location // (/tagfiles/org/apache/jsp/),
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties messages_es.properties messages_ja.properties
luehe 2002/08/20 16:44:29 Modified:jasper2/src/share/org/apache/jasper/resources messages.properties messages_es.properties messages_ja.properties Log: Added jsp.error.invoke.varAndVarReader and jsp.error.doBody.varAndVarReader error codes. Revision ChangesPath 1.26 +3 -1 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties Index: messages.properties === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- messages.properties 20 Aug 2002 15:50:23 - 1.25 +++ messages.properties 20 Aug 2002 23:44:29 - 1.26 @@ -284,4 +284,6 @@ jsp.error.fragmentwithtype=Cannot specify both 'fragment' and 'type' attributes. If 'fragment' is present, 'type' is fixed as 'javax.servlet.jsp.tagext.JspFragment' jsp.error.fragmentwithrtexprvalue=Cannot specify both 'fragment' and 'rtexprvalue' attributes. If 'fragment' is present, 'rtexprvalue' is fixed as 'true' jsp.error.fragmentWithDeclareOrScope=Both 'fragment' and 'declare' or 'scope' attributes specified in variable directive +jsp.error.invoke.varAndVarReader=Both 'var' and 'varReader' specified in jsp:invoke +jsp.error.doBody.varAndVarReader=Both 'var' and 'varReader' specified in jsp:doBody jsp.warning.bad.urlpattern.propertygroup=Bad value {0} in the url-pattern subelement in web.xml 1.7 +4 -2 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_es.properties Index: messages_es.properties === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_es.properties,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- messages_es.properties19 Aug 2002 16:54:16 - 1.6 +++ messages_es.properties20 Aug 2002 23:44:29 - 1.7 @@ -212,4 +212,6 @@ jsp.error.taglibDirective.missing.location= jsp.error.fragmentwithtype= jsp.error.fragmentWithDeclareOrScope= - +jsp.error.invoke.varAndVarReader= +jsp.error.doBody.varAndVarReader= +jsp.warning.bad.urlpattern.propertygroup= 1.6 +4 -1 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_ja.properties Index: messages_ja.properties === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_ja.properties,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- messages_ja.properties19 Aug 2002 16:54:16 - 1.5 +++ messages_ja.properties20 Aug 2002 23:44:29 - 1.6 @@ -244,3 +244,6 @@ jsp.error.taglibDirective.missing.location= jsp.error.fragmentwithtype= jsp.error.fragmentWithDeclareOrScope= +jsp.error.invoke.varAndVarReader= +jsp.error.doBody.varAndVarReader= +jsp.warning.bad.urlpattern.propertygroup= -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler ParserController.java
kinman 2002/08/20 17:45:00 Modified:jasper2/src/share/org/apache/jasper/compiler ParserController.java Log: - Minor treak to get isTagFile and Encoding right. Revision ChangesPath 1.14 +10 -12 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ParserController.java Index: ParserController.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ParserController.java,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- ParserController.java 20 Aug 2002 23:35:30 - 1.13 +++ ParserController.java 21 Aug 2002 00:45:00 - 1.14 @@ -236,6 +236,13 @@ InputStreamReader reader) throws JasperException { + newEncoding = null; + + // FIXME: Actually we should know that we are compiling a tag file + // if we begin the compilation from either the tag file + // element in a tld OR tagdir attribute in a tag directive. +isTagFile = file.startsWith( /WEB-INF/tags ) || +file.startsWith( /META-INF/tags ); PageInfo pageInfo = compiler.getPageInfo(); if (pageInfo.isXmlSpecified()) { @@ -244,7 +251,7 @@ if (pageInfo.getPageEncoding() != null) { newEncoding = pageInfo.getPageEncoding(); } - if (pageInfo.isXmlSpecified() pageInfo.getPageEncoding() != null) + if (pageInfo.isXmlSpecified() newEncoding != null) return; JspReader jspReader; @@ -270,24 +277,15 @@ } } - if (pageInfo.getPageEncoding() != null) { - // XXX isTagFile is not correctly set, but it will be determined - // elsewhere, and not here anyway. + if (newEncoding != null) { + // encoding specified in jsp-config return; } - newEncoding = null; - isTagFile = false; - // Figure out the encoding of the page // FIXME: We assume xml parser will take care of // encoding for page in XML syntax. Correct? if (!isXml) { -// Note: this currently assumes there is no XML syntax for tag -// files (as of PFD of the JSP 2.0 spec there is an XML view, -// but no XML syntax). -isTagFile = file.startsWith( /WEB-INF/tags ) || -file.startsWith( /META-INF/tags ); jspReader.reset(startMark); while (jspReader.skipUntil(%@) != null) { jspReader.skipSpaces(); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11878] New: - bad SEESIONS.ser file breaks Catalina
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=11878. 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=11878 bad SEESIONS.ser file breaks Catalina Summary: bad SEESIONS.ser file breaks Catalina Product: Tomcat 4 Version: 4.1.9 Platform: Other OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Catalina:Modules AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] I have the following behavior: (1) Start tomcat (2) hit a page in my webapp (3) Stop tomcat (4) Start Tomcat (5) Try to hit any page in my webapp and I get NullPointerException because: request.getSession(); returns null ! Now, if I remove the SESSIONS.ser from the /work directory for my webapp in between steps (3) and (4) then everything works ok. I suspect that something is wrong with Session persistence. My workaround is removing SESSIONS.ser each time I run tomcat, but I think this is a bug that needs to be fixed. (by the way, I tried to reproduce with a simple webapp and I could not. There must be something about the state in my session. I can send my SESSIONS.ser file if you need help reproducing this bug) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11879] New: - session shared between applications
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=11879. 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=11879 session shared between applications Summary: session shared between applications Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] According to the servlet2.3 specification, a new session should be created for each web application, even if the application is accessed through RequestDispatcher. So if a servlet1 in application1 access a servlet2 in application2 via the RequestDispatcher, each servlet should have it's own session. For tomcat 4.0.4, the same session is shared between the servlets. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11191] - Error while runing an app using a JDBC connection configured as JNDI resource
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=11191. 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=11191 Error while runing an app using a JDBC connection configured as JNDI resource [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2002-08-21 01:50 --- I copied the PointBase database client library to common/lib. I created a data source in Tomcat admintool as follows: Select the Data Sources entry under Resources. Select Available ActionsCreate New Data Source. Enter pointbase in the JNDI Name field. Enter jdbc:pointbase:server://localhost/sample in the Data Source URL field. Enter com.pointbase.jdbc.jdbcUniversalDriver in the JDBC Driver Class field. Enter public in the User Name and Password fields. Click the Save button. Click the Commit button. Then I restarted Tomcat. Tomcat 4.1.7 and 5.0 give the error below, and applications can't get to the database using the JNDI name. Using CATALINA_HOME: /home/sbodoff/installs/tomcat5.0 Using CATALINA_TMPDIR: /home/sbodoff/installs/tomcat5.0/temp Using JAVA_HOME: /home/sbodoff/installs/j2sdk1.4.0_01 Aug 12, 2002 11:31:37 AM org.apache.commons.modeler.Registry loadRegistry INFO: Loading registry information Aug 12, 2002 11:31:38 AM org.apache.commons.modeler.Registry getRegistry INFO: Creating new Registry instance Aug 12, 2002 11:31:40 AM org.apache.commons.modeler.Registry getServer INFO: Creating MBeanServer Aug 12, 2002 11:31:52 AM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on port 8080 Aug 12, 2002 11:31:52 AM org.apache.jk.server.JkMain init INFO: Starting Jk2, base dir= /home/sbodoff/installs/tomcat5.0 conf=/home/sbodoff/installs/tomcat5.0/conf/jk2.properties Aug 12, 2002 11:31:53 AM org.apache.jk.common.ChannelSocket init INFO: JK: listening on tcp port 8019 Aug 12, 2002 11:31:53 AM org.apache.jk.server.JkMain start INFO: APR not loaded, disabling jni components: java.io.IOException: no jkjni in java.library.path Aug 12, 2002 11:31:53 AM org.apache.jk.server.JkMain start INFO: Jk running ID=0 ... init time=522 ms GlobalResourcesLifecycleListener: Exception processing Global JNDI Resources javax.naming.NamingException: Cannot create resource instance at org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:189) at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:301) at org.apache.naming.NamingContext.lookup(NamingContext.java:834) at org.apache.naming.NamingContext.lookup(NamingContext.java:194) at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:205) at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:176) at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.lifecycleEvent(GlobalResourcesLifecycleListener.java:147) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2223) 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 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) Starting service Tomcat-Standalone J2EE SDK/1.4 Aug 12, 2002 11:32:40 AM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on port 8080 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Collector.java Generator.java PageInfo.java
kinman 2002/08/20 18:53:28 Modified:jasper2/src/share/org/apache/jasper/compiler Collector.java Generator.java PageInfo.java Log: - Silently catch SkipPageException when the page has a tag handler from tag file. Revision ChangesPath 1.4 +12 -7 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Collector.java Index: Collector.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Collector.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- Collector.java16 Jul 2002 19:30:51 - 1.3 +++ Collector.java21 Aug 2002 01:53:28 - 1.4 @@ -75,11 +75,8 @@ public class Collector { /** - * A visitor for collection info on the page - * Info collected so far: - * Maximum tag nestings. - * Whether a page or a tag element (and its body) contains any scripting - * elements. + * A visitor for collecting information on the page and the body of + * the custom tags. */ static class CollectVisitor extends Node.Visitor { @@ -90,6 +87,7 @@ private boolean includeActionSeen = false; private boolean setPropertySeen = false; private boolean hasScriptingVars = false; + private boolean tagFileSeen = false; public void visit(Node.ParamAction n) throws JasperException { if (n.getValue().isExpression()) { @@ -138,6 +136,12 @@ } public void visit(Node.CustomTag n) throws JasperException { + + // Remember if the tag handler is a tag file + if (n.getTagFileInfo() != null) { + tagFileSeen = true; + } + curTagNesting++; if (curTagNesting maxTagNesting) { maxTagNesting = curTagNesting; @@ -230,6 +234,7 @@ public void updatePageInfo(PageInfo pageInfo) { pageInfo.setMaxTagNesting(maxTagNesting); pageInfo.setScriptless(! scriptingElementSeen); + pageInfo.setHasTagFile(tagFileSeen); } } 1.73 +7 -3 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java Index: Generator.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v retrieving revision 1.72 retrieving revision 1.73 diff -u -r1.72 -r1.73 --- Generator.java20 Aug 2002 15:50:22 - 1.72 +++ Generator.java21 Aug 2002 01:53:28 - 1.73 @@ -2800,6 +2800,10 @@ */ private void generatePostamble(Node.Nodes page) { out.popIndent(); + if (pageInfo.hasTagFile()) { + // Silently catch SkipPageException + out.printil(} catch (javax.servlet.jsp.SkipPageException t) {); + } out.printil(} catch (Throwable t) {); out.pushIndent(); 1.9 +14 -5 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageInfo.java Index: PageInfo.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageInfo.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- PageInfo.java 20 Aug 2002 03:52:18 - 1.8 +++ PageInfo.java 21 Aug 2002 01:53:28 - 1.9 @@ -94,8 +94,9 @@ private boolean elEnabled = true; private boolean tagFile = false; private boolean isXml = false; -private boolean isXmlSpecified = false; // true is there is a - // is-xml element +private boolean isXmlSpecified = false; // true is there is a is-xml + // element in jsp-config +private boolean hasTagFile = false; // A custom tag is a tag file private Vector includePrelude; private Vector includeCoda; @@ -287,5 +288,13 @@ public void setIncludeCoda(Vector coda) { includeCoda = coda; +} + +public void setHasTagFile(boolean hasTag) { + hasTagFile = hasTag; +} + +public boolean hasTagFile() { + return hasTagFile; } } -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11846] - Class loader problem
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=11846. 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=11846 Class loader problem --- Additional Comments From [EMAIL PROTECTED] 2002-08-21 02:21 --- Certainly my problem is not a bug. Using Tomcat 4.1.9b, a message is printed highlighting the servlet spec which requires that libraries in WEB-INF/lib not overrise javax.servlet.*, thus weblogic.jar is not loaded. Perhaps this message could be added to 4.0.x? Not too important mind... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[daemon] more comments
I did a more detailed review of the code. Haven't made any code change yet. There are some very serious issues right now. For example, the shutdown() native method just can't work - at least based on my knowledge of unix. It is executed in the child, not in parent - and it tries to access the field storing the pid of the child, which is 0. So it'll send a signal to 0. There are other gray areas, and overall the fact that it requires an interface is the smallest problem. The major issue remains the fact that it requires the application to use a special programming model - wich is different from what most people do. You can't store the user id ( for chuid ) in the program config, and it doesn't have a config file ( where system properties, java flags, etc are stored ). There are also problems with the stop mechanism - I would expect the unix side to work the same as the windows service manager, i.e. try to restart a failed app. Right now restarting it happens only if exit status is 123 - if the server dies, it'll not be reloaded. There is a lot of usefull and nice C code - the windows part looks great, and I'm +1 on it. What I would like to do is merge the 'chuid' code into jk2 - there is already some code there, and it's quite easy. This will give tomcat ( all versions ) the ability to change the user id ( and bind on 80 ). This will be configured in the jk2.properties. That seems to be the biggest feature that tomcat uses. I'm also +1 on the unix code, as long as it is fixed to have the same behavior as the windows service manager and is made generic. The whole 'chuid' and lifecycle stuff is very shaky - again, not only because of interfaces. Keeping things simple ( SoC :-) is much better. One nice functionality is the delivery of signals. This works only for 3 signals ( actually 2, there is one cut/paste error ), with reload hardcoded to HUP. It would be much better if this would actually provide a way for apps to use unix signals in a flexible way. There is another chunk of code for starting the VM - and I need to review it closely and see how it can be merged with jk starting. I think it may be a good idea to also merge the lauching/deamon native code into jk - and eventually add back the old jserv launching capabilities. But for now it would be better to do it in tomcat. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] jakarta-servletapi-5: jsp_2_0.xsd
Patch to the XML Schema to accept the new is-xml element. Eduardo and I forgot to add it before PFD. - Mark Index: jsr152/src/share/dtd/jsp_2_0.xsd === RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/src/share/dtd/jsp_2_0.xsd,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 jsp_2_0.xsd --- jsr152/src/share/dtd/jsp_2_0.xsd 13 Aug 2002 16:20:58 - 1.1.1.1 +++ jsr152/src/share/dtd/jsp_2_0.xsd 21 Aug 2002 03:09:57 - @@ -8,7 +8,7 @@ version=2.0 xsd:annotation xsd:documentation -@(#)jsp_2_0.xsds 1.8 07/29/02 +%W% %G% /xsd:documentation /xsd:annotation @@ -138,6 +138,7 @@ - Control enabling of EL evaluation. - Control enabling of Scripting elements. - Indicate pageEncoding information. +- Indicating that a resource is a JSP document - Prelude and Coda automatic includes. /xsd:documentation @@ -159,7 +160,7 @@ xsd:annotation xsd:documentation -Can be used to easily set the isElEnabled +Can be used to easily set the isELEnabled property of a group of JSP pages. By default, the EL evaluation is enabled for Web Applications using a Servlet 2.4 or greater web.xml. @@ -193,6 +194,22 @@ Can be used to easily set the isScriptingEnabled property of a group of JSP pages. By default, scripting is enabled. + +/xsd:documentation +/xsd:annotation +/xsd:element + xsd:element name=is-xml + type=j2ee:true-falseType + minOccurs=0 +xsd:annotation +xsd:documentation + +If true, denotes that the group of resources + that match the URL pattern are JSP documents, + and thus must be interpreted as XML documents. + If false, the resources are assumed to not + be JSP documents, unless there is another + property group that indicates otherwise. /xsd:documentation /xsd:annotation -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaService.java
costin 2002/08/20 20:19:36 Modified:catalina/src/share/org/apache/catalina/startup CatalinaService.java Log: The patch to set base/home from ant. Commented out - the IU that also guesses the home ( need to also fix build.xml to package it ) Revision ChangesPath 1.3 +29 -5 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaService.java Index: CatalinaService.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaService.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- CatalinaService.java 10 Aug 2002 16:54:15 - 1.2 +++ CatalinaService.java 21 Aug 2002 03:19:36 - 1.3 @@ -81,6 +81,7 @@ import org.apache.catalina.Loader; import org.apache.commons.digester.Digester; +//import org.apache.tomcat.util.IntrospectionUtils; /** * Startup/Shutdown shell program for Catalina. The following command line @@ -160,9 +161,31 @@ public void setHome( String s ) { System.setProperty(catalina.home, s ); +} + +public void setBase( String s ) { System.setProperty(catalina.base, s ); } - + +protected void initHomeAndBase() { +//IntrospectionUtils.guessInstall(catalina.home, catalina.base, bootstrap.jar, +// org.apache.catalina.startup.CatalinaService); + +String h=System.getProperty(catalina.home); +String b=System.getProperty(catalina.base); +if( h==null b!=null ) { +setHome( b ); +System.out.println(XXX setHome + b ); +} else if( b==null h!=null ) { +setBase( h ); +System.out.println(XXX setBase + h ); +} else if( b!=null h!=null ) { +return; +} else { // b==null h==null +// Nothing yet - guessInstall can handle that. +} +} + public void setUseNaming( boolean b ) { useNaming=b; } @@ -196,6 +219,7 @@ // make sure the thread loader is set log.info(Running tomcat5); Thread.currentThread().setContextClassLoader( this.getClass().getClassLoader()); +initHomeAndBase(); if (starting) { load(); start(); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup ContextConfig.java
costin 2002/08/20 20:24:37 Modified:catalina/src/share/org/apache/catalina/startup ContextConfig.java Log: Patch from Jean-Francois Arcand to turn off validation. Also: - start using commons-logging - report the processing time for expensive operations ( right now a hard-coded limit of 200 ms ). Revision ChangesPath 1.10 +161 -109 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java Index: ContextConfig.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- ContextConfig.java20 Aug 2002 03:26:36 - 1.9 +++ ContextConfig.java21 Aug 2002 03:24:37 - 1.10 @@ -145,10 +145,11 @@ public final class ContextConfig implements LifecycleListener { +private static org.apache.commons.logging.Log log= +org.apache.commons.logging.LogFactory.getLog( ContextConfig.class ); // - Instance Variables - /** * The set of Authenticators that we know how to configure. The key is * the name of the implemented authentication method, and the value is @@ -181,21 +182,31 @@ private static final StringManager sm = StringManager.getManager(Constants.Package); - /** * The codeDigester/code we will use to process tag library * descriptor files. */ -private static Digester tldDigester = createTldDigester(); +private static Digester tldDigester = null; /** * The codeDigester/code we will use to process web application * deployment descriptor files. */ -private static Digester webDigester = createWebDigester(); +private static Digester webDigester = null; +/** + * Attribute value used to turn on/off XML validation + */ + private static boolean xmlValidation = false; + +/** + * Attribute value used to turn on/off XML namespace awarenes. + */ +private static boolean xmlNamespaceAware = false; + + // - Properties @@ -234,16 +245,17 @@ // Identify the context we are associated with try { context = (Context) event.getLifecycle(); -if (context instanceof StandardContext) { -int contextDebug = ((StandardContext) context).getDebug(); -if (contextDebug this.debug) -this.debug = contextDebug; -} +// if (context instanceof StandardContext) { +// int contextDebug = ((StandardContext) context).getDebug(); +// if (contextDebug this.debug) +// this.debug = contextDebug; +// } } catch (ClassCastException e) { -log(sm.getString(contextConfig.cce, event.getLifecycle()), e); +log.error(sm.getString(contextConfig.cce, event.getLifecycle()), e); return; } +// Called from ContainerBase.addChild() - StandardContext.start() // Process the event that has occurred if (event.getType().equals(Lifecycle.START_EVENT)) start(); @@ -268,35 +280,43 @@ stream = servletContext.getResourceAsStream (Constants.ApplicationWebXml); if (stream == null) { -log(sm.getString(contextConfig.applicationMissing)); +log.error(sm.getString(contextConfig.applicationMissing) + + context); return; } + +long t1=System.currentTimeMillis(); +if (webDigester == null){ +webDigester = createWebDigester(); +} + +URL url=null; // Process the application web.xml file synchronized (webDigester) { try { -URL url = +url = servletContext.getResource(Constants.ApplicationWebXml); - -InputSource is = new InputSource(url.toExternalForm()); -is.setByteStream(stream); -webDigester.setDebug(getDebug()); -if (context instanceof StandardContext) { -((StandardContext) context).setReplaceWelcomeFiles(true); +if( url!=null ) { +InputSource is = new InputSource(url.toExternalForm()); +is.setByteStream(stream); +webDigester.setDebug(getDebug()); +if (context instanceof
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardHost.java
costin 2002/08/20 20:26:34 Modified:catalina/src/share/org/apache/catalina Host.java catalina/src/share/org/apache/catalina/core StandardHost.java Log: Part 2 of the patch to make validation configurable. Also changed to commons-logging. ( I have most of the classes using commons-logging, but I have some extra debug and timing info I need to remove - so it'll be gradual ) Revision ChangesPath 1.2 +36 -4 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Host.java Index: Host.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Host.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- Host.java 18 Jul 2002 16:47:37 - 1.1 +++ Host.java 21 Aug 2002 03:26:34 - 1.2 @@ -173,6 +173,38 @@ public void setName(String name); +/** + * Get the server.xml host attribute's xmlNamespaceAware. + * @return true if namespace awarenes is enabled. + * + */ +public boolean getXmlNamespaceAware(); + + +/** + * Get the server.xml host attribute's xmlValidation. + * @return true if validation is enabled. + * + */ +public boolean getXmlValidation(); + + +/** + * Set the validation feature of the XML parser used when + * parsing xml instances. + * @param xmlValidation true to enable xml instance validation + */ +public void setXmlValidation(boolean xmlValidation); + + + /** + * Set the namespace aware feature of the XML parser used when + * parsing xml instances. + * @param xmlNamespaceAware true to enable namespace awareness + */ +public void setXmlNamespaceAware(boolean xmlNamespaceAware); + + // - Public Methods 1.2 +60 -7 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHost.java Index: StandardHost.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHost.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- StandardHost.java 18 Jul 2002 16:48:08 - 1.1 +++ StandardHost.java 21 Aug 2002 03:26:34 - 1.2 @@ -102,7 +102,9 @@ extends ContainerBase implements Deployer, Host { - +private static org.apache.commons.logging.Log log= +org.apache.commons.logging.LogFactory.getLog( StandardHost.class ); + // --- Constructors @@ -212,6 +214,21 @@ */ private DefaultContext defaultContext; + + +/** + * Attribute value used to turn on/off XML validation + */ + private boolean xmlValidation = false; + + +/** + * Attribute value used to turn on/off XML namespace awarenes. + */ + private boolean xmlNamespaceAware = false; + + + // - Properties @@ -502,8 +519,44 @@ } + /** + * Set the validation feature of the XML parser used when + * parsing xml instances. + * @param xmlValidation true to enable xml instance validation + */ +public void setXmlValidation(boolean xmlValidation){ +this.xmlValidation = xmlValidation; +} + +/** + * Get the server.xml host attribute's xmlValidation. + * @return true if validation is enabled. + * + */ +public boolean getXmlValidation(){ +return xmlValidation; +} /** + * Get the server.xml host attribute's xmlNamespaceAware. + * @return true if namespace awarenes is enabled. + * + */ +public boolean getXmlNamespaceAware(){ +return xmlNamespaceAware; +} + + +/** + * Set the namespace aware feature of the XML parser used when + * parsing xml instances. + * @param xmlNamespaceAware true to enable namespace awareness + */ +public void setXmlNamespaceAware(boolean xmlNamespaceAware){ +this.xmlNamespaceAware=xmlNamespaceAware; +} + +/** * Host work directory base. */ public String getWorkDir() { @@ -641,7 +694,7 @@ // Complain if no Context has been selected if (context == null) { -log(sm.getString(standardHost.mappingError, uri)); +log.error(sm.getString(standardHost.mappingError, uri)); return (null); } @@ -726,7 +779,7 @@ .newInstance();
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup HostConfig.java
costin 2002/08/20 20:29:31 Modified:catalina/src/share/org/apache/catalina/startup HostConfig.java Log: Switch to commons-logging. Added some time logging ( it shouldn't display in most cases, only for very large .wars ) Revision ChangesPath 1.2 +59 -58 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/HostConfig.java Index: HostConfig.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/HostConfig.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- HostConfig.java 18 Jul 2002 16:47:49 - 1.1 +++ HostConfig.java 21 Aug 2002 03:29:31 - 1.2 @@ -107,7 +107,9 @@ public class HostConfig implements LifecycleListener, Runnable { - + +private static org.apache.commons.logging.Log log= + org.apache.commons.logging.LogFactory.getLog( HostConfig.class ); // - Instance Variables @@ -359,7 +361,7 @@ setUnpackWARs(((StandardHost) host).isUnpackWARs()); } } catch (ClassCastException e) { -log(sm.getString(hostConfig.cce, event.getLifecycle()), e); +log.error(sm.getString(hostConfig.cce, event.getLifecycle()), e); return; } @@ -398,8 +400,8 @@ if (!(host instanceof Deployer)) return; -if (debug = 1) -log(sm.getString(hostConfig.deploying)); +if (log.isDebugEnabled()) +log.debug(sm.getString(hostConfig.deploying)); File appBase = appBase(); if (!appBase.exists() || !appBase.isDirectory()) @@ -445,14 +447,14 @@ } // Assume this is a configuration descriptor and deploy it -log(sm.getString(hostConfig.deployDescriptor, files[i])); +log.info(sm.getString(hostConfig.deployDescriptor, files[i])); try { URL config = new URL(file, null, dir.getCanonicalPath()); ((Deployer) host).install(config, null); } catch (Throwable t) { -log(sm.getString(hostConfig.deployDescriptor.error, - files[i]), t); +log.error(sm.getString(hostConfig.deployDescriptor.error, + files[i]), t); } } @@ -493,7 +495,7 @@ if (isUnpackWARs()) { // Expand and deploy this application as a directory -log(sm.getString(hostConfig.expand, files[i])); +log.info(sm.getString(hostConfig.expand, files[i])); try { URL url = new URL(jar:file: + dir.getCanonicalPath() + !/); @@ -501,21 +503,21 @@ url = new URL(file: + path); ((Deployer) host).install(contextPath, url); } catch (Throwable t) { -log(sm.getString(hostConfig.expand.error, files[i]), +log.error(sm.getString(hostConfig.expand.error, files[i]), t); } } else { // Deploy the application in this WAR file -log(sm.getString(hostConfig.deployJar, files[i])); +log.info(sm.getString(hostConfig.deployJar, files[i])); try { URL url = new URL(file, null, dir.getCanonicalPath()); url = new URL(jar: + url.toString() + !/); ((Deployer) host).install(contextPath, url); } catch (Throwable t) { -log(sm.getString(hostConfig.deployJar.error, +log.error(sm.getString(hostConfig.deployJar.error, files[i]), t); } @@ -563,15 +565,19 @@ continue; // Deploy the application in this directory -log(sm.getString(hostConfig.deployDir, files[i])); +if( log.isDebugEnabled() ) +log.debug(sm.getString(hostConfig.deployDir, files[i])); +long t1=System.currentTimeMillis(); try { URL url = new URL(file, null, dir.getCanonicalPath()); ((Deployer) host).install(contextPath, url);
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaService.java
costin 2002/08/20 20:31:18 Modified:catalina/src/share/org/apache/catalina/startup CatalinaService.java Log: Forgot the debug statement Revision ChangesPath 1.4 +4 -6 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaService.java Index: CatalinaService.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaService.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- CatalinaService.java 21 Aug 2002 03:19:36 - 1.3 +++ CatalinaService.java 21 Aug 2002 03:31:18 - 1.4 @@ -175,10 +175,8 @@ String b=System.getProperty(catalina.base); if( h==null b!=null ) { setHome( b ); -System.out.println(XXX setHome + b ); } else if( b==null h!=null ) { setBase( h ); -System.out.println(XXX setBase + h ); } else if( b!=null h!=null ) { return; } else { // b==null h==null -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core BaseInterceptor.java Container.java
billbarker2002/08/20 20:58:59 Modified:src/share/org/apache/tomcat/core BaseInterceptor.java Container.java Log: API changes to allow for saving session across Context reloading. Revision ChangesPath 1.53 +8 -0 jakarta-tomcat/src/share/org/apache/tomcat/core/BaseInterceptor.java Index: BaseInterceptor.java === RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/BaseInterceptor.java,v retrieving revision 1.52 retrieving revision 1.53 diff -u -r1.52 -r1.53 --- BaseInterceptor.java 5 Jun 2002 03:39:15 - 1.52 +++ BaseInterceptor.java 21 Aug 2002 03:58:59 - 1.53 @@ -472,7 +472,15 @@ throws TomcatException { } +/** Reload notification - called whenever a full reload is done. + This can be used to serialize sessions, log the event, + clone any resource that was class-loader dependent. + */ +public void copyContext(Request req, Context oldC, Context newC) + throws TomcatException +{ +} // Container ( or Location ) hooks --- /** Notify that certain properties are defined for a URL pattern. 1.56 +3 -1 jakarta-tomcat/src/share/org/apache/tomcat/core/Container.java Index: Container.java === RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Container.java,v retrieving revision 1.55 retrieving revision 1.56 diff -u -r1.55 -r1.56 --- Container.java5 Jun 2002 03:39:15 - 1.55 +++ Container.java21 Aug 2002 03:58:59 - 1.56 @@ -417,7 +417,8 @@ public static final int H_engineInit=16; public static final int H_preInitCheck=17; public static final int H_postInitCheck=18; -public static final int H_COUNT=19; +public static final int H_copyContext=19; +public static final int H_COUNT=20; private Hooks hooks=new Hooks(); private BaseInterceptor hooksCache[][]=null; @@ -443,6 +444,7 @@ hooks.registerHook( engineInit, H_engineInit ); hooks.registerHook( preInitCheck, H_preInitCheck ); hooks.registerHook( postInitCheck, H_postInitCheck ); + hooks.registerHook( copyContext, H_copyContext ); } public Hooks getHooks() { -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/mappers ReloadInterceptor.java
billbarker2002/08/20 21:07:35 Modified:src/share/org/apache/tomcat/modules/mappers ReloadInterceptor.java Log: Support for reloading session. Also synchronized reloading, to prevent a double-adding bug. Reported by: Hugh J.L. [EMAIL PROTECTED] Revision ChangesPath 1.15 +61 -53 jakarta-tomcat/src/share/org/apache/tomcat/modules/mappers/ReloadInterceptor.java Index: ReloadInterceptor.java === RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/mappers/ReloadInterceptor.java,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- ReloadInterceptor.java2 Oct 2001 05:50:30 - 1.14 +++ ReloadInterceptor.java21 Aug 2002 04:07:35 - 1.15 @@ -160,7 +160,6 @@ context.setAttribute( org.apache.tomcat.classloader, loader); } - public int contextMap( Request request ) { Context ctx=request.getContext(); if( ctx==null) return 0; @@ -184,59 +183,68 @@ ContextManager cm=ctx.getContextManager(); if( fullReload ) { - Vector sI=new Vector(); // saved local interceptors - BaseInterceptor[] eI;// all exisiting interceptors - - // save the ones with the same context, they are local - eI=ctx.getContainer().getInterceptors(); - for(int i=0; i eI.length ; i++) - if(ctx == eI[i].getContext()) sI.addElement(eI[i]); - - Enumeration e; - // Need to find all the config that - // was read from server.xml. - // So far we work as if the admin interface was - // used to remove/add the context. - // Or like the deploytool in J2EE. - Context ctx1=cm.createContext(); - ctx1.setContextManager( cm ); - ctx1.setPath(ctx.getPath()); - ctx1.setDocBase(ctx.getDocBase()); - ctx1.setReloadable( ctx.getReloadable()); - ctx1.setDebug( ctx.getDebug()); - ctx1.setHost( ctx.getHost()); - ctx1.setTrusted( ctx.isTrusted()); - e=ctx.getHostAliases(); - while( e.hasMoreElements()) - ctx1.addHostAlias( (String)e.nextElement()); - - cm.removeContext( ctx ); - - cm.addContext( ctx1 ); - - // put back saved local interceptors - e=sI.elements(); - while(e.hasMoreElements()){ - BaseInterceptor savedI=(BaseInterceptor)e.nextElement(); - - ctx1.addInterceptor(savedI); - savedI.setContext(ctx1); - savedI.reload(request,ctx1); + synchronized(ctx) { + if(ctx.getState() == Context.STATE_NEW) + return 0; // Already reloaded. + Vector sI=new Vector(); // saved local interceptors + BaseInterceptor[] eI;// all exisiting interceptors + + // save the ones with the same context, they are local + eI=ctx.getContainer().getInterceptors(); + for(int i=0; i eI.length ; i++) + if(ctx == eI[i].getContext()) sI.addElement(eI[i]); + + Enumeration e; + // Need to find all the config that + // was read from server.xml. + // So far we work as if the admin interface was + // used to remove/add the context. + // Or like the deploytool in J2EE. + Context ctx1=cm.createContext(); + ctx1.setContextManager( cm ); + ctx1.setPath(ctx.getPath()); + ctx1.setDocBase(ctx.getDocBase()); + ctx1.setReloadable( ctx.getReloadable()); + ctx1.setDebug( ctx.getDebug()); + ctx1.setHost( ctx.getHost()); + ctx1.setTrusted( ctx.isTrusted()); + e=ctx.getHostAliases(); + while( e.hasMoreElements()) + ctx1.addHostAlias( (String)e.nextElement()); + + BaseInterceptor ri[] = + cm.getContainer().getInterceptors(Container.H_copyContext); + int i; + for( i=0; i ri.length; i++) { + ri[i].copyContext(request, ctx, ctx1); + } + cm.removeContext( ctx ); + + cm.addContext( ctx1 ); + + // put back saved local interceptors + e=sI.elements(); + while(e.hasMoreElements()){ + BaseInterceptor
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config LoaderInterceptor11.java
billbarker2002/08/20 21:08:43 Modified:src/share/org/apache/tomcat/modules/config LoaderInterceptor11.java Log: Session reloading support on Context reload. Revision ChangesPath 1.25 +23 -5 jakarta-tomcat/src/share/org/apache/tomcat/modules/config/LoaderInterceptor11.java Index: LoaderInterceptor11.java === RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/LoaderInterceptor11.java,v retrieving revision 1.24 retrieving revision 1.25 diff -u -r1.24 -r1.25 --- LoaderInterceptor11.java 11 Jan 2002 07:01:24 - 1.24 +++ LoaderInterceptor11.java 21 Aug 2002 04:08:43 - 1.25 @@ -96,6 +96,7 @@ Vector additionalJars=new Vector(); String additionalJarsS=null; String jarSeparator=:; +static final String clAttribute = org.apache.tomcat.classloader; public LoaderInterceptor11() { } @@ -230,13 +231,30 @@ } +/** setup the ClassLoader for this context. + * If this is a re-loaded context, do nothing. + */ public void contextInit( Context ctx ) throws TomcatException { // jsp will add it's own stuff - prepareClassLoader( ctx ); + if(ctx.getAttribute(clAttribute) == null) { + prepareClassLoader( ctx ); + } } - + +public void copyContext(Request req, Context oldC, Context newC) + throws TomcatException { + if(debug 0) + log( Reload event + newC.getPath() ); + // construct a new loader + ClassLoader oldLoader=oldC.getClassLoader(); + + // will be used by reloader or other modules to try to + // migrate the data. + newC.getContainer().setNote( oldLoader, oldLoader); +} + /** Construct another class loader, when the context is reloaded. */ public void reload( Request req, Context context) throws TomcatException { @@ -259,7 +277,7 @@ } context.setClassLoader( loader ); - context.setAttribute( org.apache.tomcat.classloader, loader); + context.setAttribute( clAttribute, loader); } /** Initialize the class loader. @@ -309,7 +327,7 @@ context.setClassLoader( loader ); // support for jasper and other applications - context.setAttribute( org.apache.tomcat.classloader,loader); + context.setAttribute(clAttribute, loader); } /** Override this method to provide an alternate loader @@ -405,7 +423,7 @@ if (k.equals(org.apache.tomcat.jsp_classpath)) { return getClassPath(ctx); } - if(k.equals(org.apache.tomcat.classloader)) { + if(k.equals(clAttribute)) { return ctx.getClassLoader(); } -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11882] New: - Variable may not have been initialized
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=11882. 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=11882 Variable may not have been initialized Summary: Variable may not have been initialized Product: Tomcat 4 Version: 4.0 Final Platform: Sun OS/Version: Solaris Status: NEW Severity: Major Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am using the following setup: - Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode) - jakarta-tomcat-4.0.4 - Solaris 8 - Apache 1.3.20 via mod_jk From time to time, when I modify my JSP file, I get an error Variable xxx may not have been initialized. - Specifically, it happens on StringBuffer variables, and the out stream. - It usually happens right after I modify the JSP code, (so could it be a compiler issue)? - Right after I get the error, I restart Tomcat, and everything works okay. I tried it on both binaries, the LE and the FULL edition of Tomcat. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SimpleSessionStore.java
billbarker2002/08/20 21:11:56 Modified:src/share/org/apache/tomcat/modules/session SimpleSessionStore.java Log: Support for saving session on Context reloading. This version maximizes code re-use, at the expense of a some-what dirty lifecycle. However, since the current implementation notifies lifecycle events from the Facade, it is still valid from the point of view of the Servlet Spec. Reported By: Hugh J.L. [EMAIL PROTECTED] Revision ChangesPath 1.20 +100 -38 jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SimpleSessionStore.java Index: SimpleSessionStore.java === RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SimpleSessionStore.java,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- SimpleSessionStore.java 3 Apr 2002 00:02:14 - 1.19 +++ SimpleSessionStore.java 21 Aug 2002 04:11:56 - 1.20 @@ -88,6 +88,7 @@ int maxActiveSessions = -1; int size=16; int max=256; +static final String SESSIONS_RELOAD = tomcat.sessions.reload; public SimpleSessionStore() { } @@ -114,56 +115,84 @@ } -public void reload( Request req, Context ctx ) throws TomcatException { - ClassLoader newLoader = ctx.getClassLoader(); - SimpleSessionManager sM = getManager( ctx ); +public void copyContext(Request req, Context oldC, Context newC) + throws TomcatException { + contextInit(newC); + ClassLoader oldLoader = oldC.getClassLoader(); + SimpleSessionManager sM = getManager( oldC ); + SimpleSessionManager sMnew = getManager( newC ); // remove all non-serializable objects from session Enumeration sessionEnum=sM.getSessions(); while( sessionEnum.hasMoreElements() ) { ServerSession session = (ServerSession)sessionEnum.nextElement(); - - ClassLoader oldLoader=(ClassLoader)ctx.getContainer(). - getNote(oldLoader); - - Hashtable newSession=new Hashtable(); + ServerSession newS = sMnew.cloneSession(req, newC, + session.getId().toString()); Enumeration e = session.getAttributeNames(); - while( e.hasMoreElements() ) { + while( e.hasMoreElements() ) { String key = (String) e.nextElement(); Object value = session.getAttribute(key); - - if( value.getClass().getClassLoader() != oldLoader ) { - // it's loaded by the parent loader, no need to reload - newSession.put( key, value ); - } else if ( value instanceof Serializable ) { - Object newValue = - ObjectSerializer.doSerialization( newLoader, - value); - newSession.put( key, newValue ); - } - } - // Remove all objects we know how to handle - e=newSession.keys(); - while( e.hasMoreElements() ) { - String key = (String) e.nextElement(); - session.removeAttribute(key); + newS.setAttribute(key, value); } + } + newC.getContainer().setNote(SESSIONS_RELOAD, req); +} - if( debug 0 ) log(Prepare for reloading, SUSPEND + session ); - // If anyone can save the rest of the attributes or at least notify - // the owner... - session.setState( ServerSession.STATE_SUSPEND, req ); +private void processSession(ServerSession session, + ClassLoader oldCL, ClassLoader newCL) + throws TomcatException { + + Hashtable newSession=new Hashtable(); + Enumeration e = session.getAttributeNames(); + while( e.hasMoreElements() ) { + String key = (String) e.nextElement(); + Object value = session.getAttribute(key); + if( value.getClass().getClassLoader() != oldCL ) { + // it's loaded by the parent loader, no need to reload + newSession.put( key, value ); + } else if ( value instanceof Serializable ) { + Object newValue = + ObjectSerializer.doSerialization( newCL, + value); + newSession.put( key, newValue ); + } + } + // If saving back to the same session. + // Remove all objects we know how to handle + e=newSession.keys(); + while( e.hasMoreElements() ) { + String key = (String) e.nextElement(); + session.removeAttribute(key); + } + + if( debug 0 ) log(Prepare for reloading, SUSPEND + session ); +
DO NOT REPLY [Bug 11883] New: - Unable to use Dynamic attributes
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=11883. 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=11883 Unable to use Dynamic attributes Summary: Unable to use Dynamic attributes Product: Tomcat 5 Version: Unknown Platform: All OS/Version: All Status: NEW Severity: Blocker Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The JSP spec says A tag handler should implement the DynamicAttributes interface to be able to accept dynamic attributes However ,when a tag handler that implements DynamicAttributes is compiled , an error is thrown : Tag Handler name should be declared abstract ;it does not define setDynamicAttribute(java.lang.String,java.lang.String,java.lang.Object) in name This causes a problem as according to the spec the container would invoke the setDynamic Attributes method at runtime. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11884] New: - getParent in a SimpleTag implementation returns a Tag
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=11884. 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=11884 getParent in a SimpleTag implementation returns a Tag Summary: getParent in a SimpleTag implementation returns a Tag Product: Tomcat 5 Version: Unknown Platform: All OS/Version: All Status: NEW Severity: Critical Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If getparent is called within a tag handler implementing SimpleTag , an instance of javax.servlet.jsp.tagext.Tag is returned. According to the spec javax.servlet.jsp.tagext.Tag adapter should be returned -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]