DO NOT REPLY [Bug 27894] New: - jmx throws exception if TC installation path contains spaces
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27894. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27894 jmx throws exception if TC installation path contains spaces Summary: jmx throws exception if TC installation path contains spaces Product: Tomcat 5 Version: 5.0.19 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I tried to run TC 5.0.19 with mx4j-1.1.1 and mc4j-1.2beta4. As I read in http://mc4j.sourceforge.net/usageTomcat.html that the JMX RI (JSR 160) in tomcat is still not working I followed the instructions given there to use mx4j 1.1.1. Whenever I install tomcat to a path that contains spaces (e.g. the default C:\...\Apache Software Foundation\Tomcat 5.0) I get the following exception at startup: --snip 24.03.2004 08:57:00 org.apache.jk.common.JkMX loadAdapter SCHWERWIEGEND: MX4j RMI adapter not loaded: javax.management.MBeanException: nested exception is javax.naming.CommunicationException [Root exception is java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: java.net.MalformedURLException: no protocol: Software] 24.03.2004 08:57:00 org.apache.jk.common.JkMX loadAdapter WARNUNG: No adaptors were loaded but mx.enabled was defined. --snap When move the TC homedir to a path that does NOT contain spaces, anything works fine!! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16830] - Jasper do not reset BodyContent for tags with BodySupport and empty content
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=16830. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=16830 Jasper do not reset BodyContent for tags with BodySupport and empty content --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 08:23 --- Thx Kin-Man! Your comments are greatly appreciated. Anyway, you're right that the spec does not explicitly tell what should the container do and what the tag developer must expect from the container when tag pooling is in place. Isn't it better to push the JSP leads to clarify this, instead of making assumptions for implicit mechanism? And the spec is rather thin on the explanation of the INIT PROTOCOL (what are those AttSet? What the container must do after doEndTag?). BTW, is there any really good explanation of the life cycle of a BodyTag with a tag pooling container on the Net somewhere? I guess a backdoor for tag developers is to use the TryCatchFinally fonctionnality to reset the bodycontent, right? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16830] - Jasper do not reset BodyContent for tags with BodySupport and empty content
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=16830. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=16830 Jasper do not reset BodyContent for tags with BodySupport and empty content --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 08:44 --- Thanks for the lengthy explanation! Unfortunately there is some degree of freedom as to the correct interpretation of the spec. If you consider the spec in absence of tag pooling then it is clear, that the body content of a tag that has no body remains unchanged. Typically this will be 'null' since tag implementors usually won't initialize this to something else (they would have to implement BodyContent for this sole purpose). Now, tag pooling is supposed to *not* change the semantics of a JSP. In this case not invoking setBodyContent(null) would better meet this requirement than not doing it. The only solution I can see that is both conformant to the spec and working would be to request of each tag implementor that he/she resets bodyContent to 'null' in doEndTag(). I am just not sure whether that is possible/desired in all situations. Maybe there are cases where one wants access to the body content even after doEndTag() - maybe for the doEndTag() method of an enclosing tag. We'll probably need another life cycle event in interface Tag that is invoked when an instance returns to a pool. (release() is invoked when the tag is completely discarded). That would be the best solution IMHO. Thanks for listening! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27884] - mod_jk2 making multiple requests when client cancels the load of the page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27884. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27884 mod_jk2 making multiple requests when client cancels the load of the page --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 08:48 --- Which version of jk2 ? Take a look at the latest in CVS which will be tagged 2.0.4 today - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27893] - Cann't get UTF-8 parameter when set contentType=text/html;charset=UTF-8.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27893. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27893 Cann't get UTF-8 parameter when set contentType=text/html;charset=UTF-8. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 09:10 --- Please look at the HTTP connector documentation: URI parameters are now handled differently by default. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Could SPNEGO supported by Tomcat?
Our thin-client J2EE app run on JBoss 3.x + Tomcat 4.1.x. We want to integrate our thin-clinet J2EE application with MS Active Directory, so that a user with IE 6.0 will not need to sign in to acces our application after he/she has signed in to his/her Windows workstation. IE 6.0 support SPNEGO. Could any one tell me if there is any implementation of SPNEGO for Tomcat. I search the Internet, and do not find any solution about it, so I think if I could add the support of SPNEGO to Tomcat 4.x (for our use only). Is it valuabe to do it? I am new to tomcat's source code. I browse the source code, and could not figure out how the security works in the source code. Could anyone kindly tell me where to find the code that secure the web resource, or where and when an instance of an Authenticator( for example, FormAuthenticator or BasicAuthenticator) is instantiated. Thank you very much. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27894] - jmx throws exception if TC installation path contains spaces
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27894. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27894 jmx throws exception if TC installation path contains spaces [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 09:25 --- Honestly, this is not worth fixing, since the workaround is simple enough. To get JMX remote support, use JDK 1.5.0 (I found out the support was outstanding, and decided as a result that it was not worth spending time on this - wise decision, since we would not have been able to actually ship the result anyway). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Re: Does Geronimo use tomcat?
Sriram N wrote: --- n. alex rupp [EMAIL PROTECTED] wrote: It's true. Tomcat's 95% ready. It took me about a week to learn enough about GBeans and Catalina to get a bolt-on version of Tomcat running inside Geronimo, so we don't need a jumpstart. It isn't in the code base right now because there are some special build/maven-related parlour tricks that need to be performed in order to get it integrated with the normal build, and one Mr. Sundstrom has taken charge of that effort. Once he gets it integrated into the build, you'll be able to use Tomcat. I don't know if T5'll ship with the first version of Geronimo or not--I don't hear much from Dain or Jeremy these days. They're somewhere near London, probably pub crawling. However, I must warn you. Tomcat is not capable of being truly integrated into the Geronimo environment, because it does not use a componentized architectural style. Tomcat is very much an application, which can be bolted onto the side of Geronimo, but cannot be broken down and encapsulated into GBeans which are then able to be individually managed by the container. Believe me, I spent a month and a half researching the problem, and I did not arrive at this conclusion lightly. It isn't that Tomcat is designed poorly, just that it wasn't designed to be embedded. This poses problems if you're trying to use Tomcat's built-in JMX to connect with other GBeans. It also means you won't be able to take advantage of the distributed configurations, dependency management, application lifecycle, and all of the other things a real integration with a JSR-77 compliant container would buy you. I was not happy to make this realization, but it's given me a whole new appreciation for Jetty (not that I was really lacking in that department to begin with). This is why I'll be focusing my time and energy in the future on helping Greg, Jan and Jules with a true integration of Jetty, or some other solution that's amiable to them and the other project commiters. Hopefully, as more IoC-3 style constructor dependency injection containers (like the GBean / Plexus / Pico containers) start becoming available, our web server solutions will get more componentized. In the mean time we'll keep the Tomcat bolt-on available in case anyone desperately needs it, and give whatever constructive advice we can regarding the subject. If not here, then definitely on IRC. (as Greg and others have mentioned, if you stick to the specification then you've got nothing at all to worry about.) Cheers, hope you guys are all doing well : ) Great news to me. Somehow Costin (and I) managed to do a good integration with JBoss :) I'm definitely not going to spit on competitive advantage. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27897] New: - Conflict between ant.jar in common/lib and xalan method: org.apache.xalan.xslt.EnvironmentCheck.checkEnvironment
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27897. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27897 Conflict between ant.jar in common/lib and xalan method: org.apache.xalan.xslt.EnvironmentCheck.checkEnvironment Summary: Conflict between ant.jar in common/lib and xalan method: org.apache.xalan.xslt.EnvironmentCheck.checkEnvironment Product: Tomcat 5 Version: 5.0.19 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] It seems that the ant jar (1.6) bundled with this version of tomcat (5.0.19) creates a conflict that causes a strange exception calling the following method of Xalan (tested with Xalan 2.4D1 and latest 2.5.2): org.apache.xalan.xslt.EnvironmentCheck.checkEnvironment The exception is: java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/AntMain (I've just posted the same bug for Tomcat 4.0.30: bug #27253) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27897] - Conflict between ant.jar in common/lib and xalan method: org.apache.xalan.xslt.EnvironmentCheck.checkEnvironment
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27897. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27897 Conflict between ant.jar in common/lib and xalan method: org.apache.xalan.xslt.EnvironmentCheck.checkEnvironment [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID Summary|Conflict between ant.jar in |Conflict between ant.jar in |common/lib and xalan method:|common/lib and xalan method: |org.apache.xalan.xslt.Enviro|org.apache.xalan.xslt.Enviro |nmentCheck.checkEnvironment |nmentCheck.checkEnvironment --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 10:03 --- Then use another Ant release ;) We bundle the latest Ant with Tomcat (5.0.20 has Ant 1.6.1). If it has a problem somewhere, well, too bad. Please don't swamp bugzilla with that kind of issues: it's a lot more productive to post on tomcat-user. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27647] - Can't compile jk_isapi (Windows XP)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27647. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27647 Can't compile jk_isapi (Windows XP) --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 10:19 --- I read the mailing list that you want tag for 2.0.4. Great but the isapi don't compile (CVS HEAD 24.03.04) Can you document your way, to build the 2.0.4 release with ISAPI ? regards Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16830] - Jasper do not reset BodyContent for tags with BodySupport and empty content
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=16830.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=16830
Jasper do not reset BodyContent for tags with BodySupport and empty content
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |
--- Additional Comments From [EMAIL PROTECTED] 2004-03-24 10:15 ---
1) We are NOT talking about SKIP_BODY. Here are example:
---
pc:out value=${null}Default/c:out
pc:out value=${null}/c:out
---
Output:
---
pDefault
pDefault
---
Should be:
---
pDefault
p
---
c:out in both cases returns EVAL_BODY_BUFFERED and according to Kin in 1.2 case
setBodyContent MUST be called:
JSP 1.2 spec, p 177 (JSP.10.2 BodyTag) Under Properties:
The setter method (setBodyContent) will only be invoked if
doStartTag( ) returns EVAL_BODY_BUFFERED.
---
According to JSP 2.0 it should not be called, so we have a collision.
Even more, according to JSP 2.0 JSP.13.2.3.3 Methods of BodyTagSupport
public BodyContent getBodyContent()
Get current bodyContent.
Returns: the body content.
It must work OK in all cases, while it's not and even can't because it has no
means to reset it's bodyContent (we are not required to call super.doStartTag())
if working according to JSP 2.0 specs. It does not say that return is undefined
if tag is empty (remember, we are not talking about SKIP_BODY).
My proposal that I think will make everything OK is another patch that will send
tags with equal attributes but ones using and ones not using body to two
different pools. Actually this was my first thought, but this would require more
deep knowledge of Jasper code I do not have (yet, with all this bugs :( ).
I suppose this will fix the problem and won't violate any specs (but JSP 1.2
that still require for setBodyContent to be called if tag returned
EVAL_BODY_BUFFERED no matter if body was empty or not).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14359] - largefile option has no effect
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=14359. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=14359 largefile option has no effect --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 10:43 --- So how to resolve this problem (Code of a method longer than 65535 bytes)??? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: DO NOT REPLY [Bug 27647] - Can't compile jk_isapi (Windows XP)]
Mladen could you verify this ? It could be a show stopper for 2.0.4 release Thanks ---BeginMessage--- DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27647. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27647 Can't compile jk_isapi (Windows XP) --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 10:19 --- I read the mailing list that you want tag for 2.0.4. Great but the isapi don't compile (CVS HEAD 24.03.04) Can you document your way, to build the 2.0.4 release with ISAPI ? regards Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27900] New: - If i open a page in a frame the error invalid direct reference..
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27900. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27900 If i open a page in a frame the error invalid direct reference.. Summary: If i open a page in a frame the error invalid direct reference.. Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Other Status: NEW Severity: Minor Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have an application on a tomcat 4.1.24 with frames. One Frame for the navigation and an other for the dialoges. Now i want to open a application with an form based login (i don´t post to the j_security_check directly) from an other tomcat 4.1.24 in the dialog frame. If i open it in the dialog frame i get an error invalid direct reference to form login page. if I open it in a new window it works? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27647] - Can't compile jk_isapi (Windows XP)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27647. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27647 Can't compile jk_isapi (Windows XP) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 11:30 --- Well you should upgrade to a recent dev tools Here is the Mladen comment on the commit : Remove the SF_NOTIFY_AUTH_COMPLETE define checking. If someone wishes to compile jk2 he will anyhow need the platform SDK. Any sdk since year 2000 has that defined in the httpfilt.h - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-site/xdocs bugreport.xml
remm2004/03/24 03:51:04
Modified:docs bugreport.html
docs/faq tomcatuser.html
docs/faq/printer tomcatuser.html
xdocsbugreport.xml
Log:
- Add missing bug link.
Revision ChangesPath
1.21 +3 -16 jakarta-tomcat-site/docs/bugreport.html
Index: bugreport.html
===
RCS file: /home/cvs/jakarta-tomcat-site/docs/bugreport.html,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- bugreport.html9 Mar 2004 20:11:44 - 1.20
+++ bugreport.html24 Mar 2004 11:51:04 - 1.21
@@ -1,21 +1,5 @@
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
-!--
-Copyright 1999-2004 The Apache Software Foundation
-Licensed under the Apache License, Version 2.0 (the License);
-you may not use this file except in compliance with the License.
-You may obtain a copy of the License at
-
-http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an AS IS BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
---
-
-
!-- Content Stylesheet for Site --
@@ -220,6 +204,9 @@
here/a.br /
Search the Tomcat 4 bug database
a href=http://nagoya.apache.org/bugzilla/query.cgi?product=Tomcat%204;
+ here/a.br /
+ Search the Tomcat 5 bug database
+ a href=http://nagoya.apache.org/bugzilla/query.cgi?product=Tomcat%205;
here/a.br /
/p
/blockquote
1.6 +173 -173 jakarta-tomcat-site/docs/faq/tomcatuser.html
Index: tomcatuser.html
===
RCS file: /home/cvs/jakarta-tomcat-site/docs/faq/tomcatuser.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- tomcatuser.html 26 Feb 2004 17:30:01 - 1.5
+++ tomcatuser.html 24 Mar 2004 11:51:04 - 1.6
@@ -1,174 +1,174 @@
-htmlheadMETA http-equiv=Content-Type content=text/html;
charset=iso-8859-1titleTomcat FAQ - About Tomcat User/titlemeta value=Tim
Funk name=authormeta value=[EMAIL PROTECTED] name=emailstyle
- dt { font-size : larger; font-weight : bold }
- dd {padding-bottom : 10px;}
-/style/headbody vlink=#525D76 alink=#525D76 link=#525D76
text=#00 bgcolor=#fftable cellspacing=4 width=100%
border=0!--PAGE HEADER--trtd colspan=2!--JAKARTA LOGO--a
href=http://jakarta.apache.org/;img border=0 alt=The Jakarta Project
align=left src=http://jakarta.apache.org//images/jakarta-logo.gif;/a!--PROJECT
LOGO--a href=http://jakarta.apache.org/tomcat/;img border=0 alt=
- Tomcat FAQ
- align=right src=../images/tomcat.gif/a/td/tr!--HEADER
SEPARATOR--trtd colspan=2hr size=1 noshade=/td/trtr!--LEFT SIDE
NAVIGATION--td nowrap=true valign=top
width=20%pstrongLinks/strong/pullia href=..Tomcat
Home/a/lilia href=index.htmlFAQ
Home/a/li/ulpstrongContents/strong/pullia
href=bugs.htmlBugs/a/lilia href=classnotfound.htmlClass Not
Found/a/lilia href=connectors.htmlConnectors/a/lilia
href=database.htmlDatabase/a/lilia
href=deployment.htmlDeployment/a/lilia
href=http://nagoya.apache.org/wiki/apachewiki.cgi?Tomcat/Howto;How do
I/a/lilia href=unix.htmlLinux / Unix/a/lilia
href=memory.htmlMemory/a/lilia href=meta.htmlMeta/a/lilia
href=misc.htmlMiscellaneous/a/lilia href=performance.htmlMonitoring /
Performance/a/lilia
href=http://nagoya.apache.org/wiki/apachewiki.cgi?Tomcat/Links;Other
Resources/a/lilia href=security.htmlSecurity/a/lilia
href=version.htmlWhich Version/a/lilia href=tomcatuser.htmlTomcat User
List/a/lilia href=windows.htmlWindows/a/li/ul/td!--RIGHT SIDE MAIN
BODY--td align=left valign=top width=80%table cellspacing=4 width=100%
border=0trtd nowrap=true valign=top align=lefth1Tomcat
FAQ/h1h2About Tomcat User/h2/tdtd nowrap=true valign=top
align=rightsmalla href=printer/tomcatuser.htmlimg alt=Printer Friendly
Version border=0 src=../images/printer.gifbrprint-friendlybrversion
-/a/small/td/tr/tabletable cellpadding=2
cellspacing=0 border=0trtd bgcolor=#525D76font
face=arial,helvetica.sanserif color=#ffa
name=PrefacestrongPreface/strong/a/font/td/trtrtdblockquote
-p
-This is about the Tomcat user list.
-a href=mailto:[EMAIL PROTECTED]Subscribe/a
-and
-a href=http://jakarta.apache.org/site/mail.html;general information/a
-can be found
-a href=http://jakarta.apache.org/site/mail2.html;here/a.
-It is a high volume list! For those who can't handle that kind of traffic,
-you can also get it in
DO NOT REPLY [Bug 27458] - Tomcat Online Documentation: Missing links to search for tomcat5 bugs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27458. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27458 Tomcat Online Documentation: Missing links to search for tomcat5 bugs [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27902] New: - Tomcat webapps on a Network Drive
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27902. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27902 Tomcat webapps on a Network Drive Summary: Tomcat webapps on a Network Drive Product: Tomcat 4 Version: 4.1.9 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] First, I'm going to describe our system: We are working with Network Appliance FILER 810c (NetApp DataOnTap Release 6.4.3 S.O.) storage system, used to store our application data. Our infrastructure is composed by several machines with a Tomcat installation (v4.1.9) and all the application data in our storage system. Our server.xml is: Server port=8005 shutdown=SHUTDOWN debug=0 Listener className=org.apache.catalina.mbeans.ServerLifecycleListener debug=0/ Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener debug=0/ GlobalNamingResources Environment name=simpleValue type=java.lang.Integer value=30/ Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved /Resource ResourceParams name=UserDatabase parameter namefactory/name valueorg.apache.catalina.users.MemoryUserDatabaseFactory/value /parameter parameter namepathname/name valueconf/tomcat-users.xml/value /parameter /ResourceParams /GlobalNamingResources Service name=Tomcat-Standalone Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8080 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=443 acceptCount=10 debug=0 connectionTimeout=2 useURIValidationHack=false / Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8009 minProcessors=5 maxProcessors=75 enableLookups=false acceptCount=10 debug=0 connectionTimeout=2 useURIValidationHack=false scheme=https secure=true tomcatAuthentication=false protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/ Engine name=Standalone defaultHost=localhost debug=0 Logger className=org.apache.catalina.logger.FileLogger prefix=catalina_log. suffix=.txt timestamp=true directory=logs/server / Realm className=org.apache.catalina.realm.UserDatabaseRealm debug=0 resourceName=UserDatabase/ Host name=localhost debug=0 appBase=h:/apps unpackWARs=true autoDeploy=true Valve className=org.apache.catalina.valves.AccessLogValve directory=logs/server prefix=localhost_access_log. suffix=.txt pattern=common resolveHosts=false/ Logger className=org.apache.catalina.logger.FileLogger directory=logs/server prefix=localhost_log. suffix=.txt timestamp=true/ Logger className=org.apache.catalina.logger.FileLogger directory=logs/server prefix=localhost_admin_log. suffix=.txt timestamp=true/ Context path=/jsiom docBase=jsiom debug=0 reloadable=true / /Host /Engine /Service /Server We has modified the 'appBase' attribute on the 'Host' tag, to point tomcat to our repository of web applications at our storage system named formerly. Note that 'h:/apps' is a network unit on the machine pointing to our file on \\filer2des. And the problem: When we start Tomcat, everything goes well, but certain time after, Tomcat seems to lose its references to libraries stored at the lib directory of the webapp. And produces this type of error (this is a class in a jar file on the lib directory): java.lang.NoClassDefFoundError: javax/xml/soap/Detail at org.apache.axis.AxisFault.output(AxisFault.java:317) at org.apache.axis.SOAPPart.writeTo(SOAPPart.java:262) at org.apache.axis.SOAPPart.getAsString(SOAPPart.java:472) at org.apache.axis.SOAPPart.getAsBytes(SOAPPart.java:379) at org.apache.axis.Message.getContentType(Message.java:400) at org.apache.axis.transport.http.AxisServlet.doPost (AxisServlet.java:721) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at org.apache.axis.transport.http.AxisServletBase.service (AxisServletBase.java:335) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
DO NOT REPLY [Bug 16830] - Jasper do not reset BodyContent for tags with BodySupport and empty content
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=16830. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=16830 Jasper do not reset BodyContent for tags with BodySupport and empty content --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 12:15 --- Regarding c:out, we fixed this problem by setting bodyContent=null at doStartTag() - see bug 26320 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27893] - Cann't get UTF-8 parameter when set contentType=text/html;charset=UTF-8.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27893. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27893 Cann't get UTF-8 parameter when set contentType=text/html;charset=UTF-8. [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 13:04 --- Thank you for answer. Now i know the attribute URIEncoding and useBodyEncodingForURI. In my tomcat5 they was default value ISO-8859-1 and false. But now i has the new question why the JSP without content type description can get right value if Request.setCharacterEncoding is invalib. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27893] - Cann't get UTF-8 parameter when set contentType=text/html;charset=UTF-8.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27893. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27893 Cann't get UTF-8 parameter when set contentType=text/html;charset=UTF-8. [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 2.0.4 to be tagged soon
I've got no report or showstopper which prevent me to tag jk2 2.0.4. I'll tag it later this afternoon (CET) and prepare the source tarball. Thanks to stop commit on jk2 native - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_global.h
hgomez 2004/03/24 05:32:20 Modified:jk/native2/include jk_global.h Log: Mark as release Revision ChangesPath 1.24 +2 -2 jakarta-tomcat-connectors/jk/native2/include/jk_global.h Index: jk_global.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_global.h,v retrieving revision 1.23 retrieving revision 1.24 diff -u -r1.23 -r1.24 --- jk_global.h 21 Mar 2004 09:39:57 - 1.23 +++ jk_global.h 24 Mar 2004 13:32:20 - 1.24 @@ -60,7 +60,7 @@ #define JK_VERBETA 0 #define JK_BETASTRING 1 /* set JK_VERISRELEASE to 1 when release (do not forget to commit!) */ -#define JK_VERISRELEASE 0 +#define JK_VERISRELEASE 1 /** END OF AREA TO MODIFY BEFORE RELEASING */ #define PACKAGE mod_jk2/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_global.h
hgomez 2004/03/24 05:40:48 Modified:jk/native2/include jk_global.h Log: jk2 2.0.4 has been tagged as jk2_2_0_4. Switch to jk2 2.0.5-dev Revision ChangesPath 1.25 +4 -4 jakarta-tomcat-connectors/jk/native2/include/jk_global.h Index: jk_global.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_global.h,v retrieving revision 1.24 retrieving revision 1.25 diff -u -r1.24 -r1.25 --- jk_global.h 24 Mar 2004 13:32:20 - 1.24 +++ jk_global.h 24 Mar 2004 13:40:48 - 1.25 @@ -53,14 +53,14 @@ /** START OF AREA TO MODIFY BEFORE RELEASING */ #define JK_VERMAJOR 2 #define JK_VERMINOR 0 -#define JK_VERFIX 4 -#define JK_VERSTRING2.0.4 +#define JK_VERFIX 5 +#define JK_VERSTRING2.0.5 /* Beta number */ #define JK_VERBETA 0 #define JK_BETASTRING 1 /* set JK_VERISRELEASE to 1 when release (do not forget to commit!) */ -#define JK_VERISRELEASE 1 +#define JK_VERISRELEASE 0 /** END OF AREA TO MODIFY BEFORE RELEASING */ #define PACKAGE mod_jk2/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jk2 2.0.4 tagged
jk2 2.0.4 has been tagged. jk2_2_0_4 We're now in HEAD at 2.0.5-dev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 2.0.4 tagged
-Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 24, 2004 2:41 PM To: Tomcat Developers List Subject: jk2 2.0.4 tagged jk2 2.0.4 has been tagged. jk2_2_0_4 We're now in HEAD at 2.0.5-dev Cool :) Will you build the sources? MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 2.0.4 tagged
Mladen Turk wrote: -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 24, 2004 2:41 PM To: Tomcat Developers List Subject: jk2 2.0.4 tagged jk2 2.0.4 has been tagged. jk2_2_0_4 We're now in HEAD at 2.0.5-dev Cool :) Will you build the sources? I'm preparing a source tarball, and will build Linux binaries for Fedora Core 1, Suse 9.0 and Suse SLES 8.0 (PPC). Others archs, are welcomed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27884] - mod_jk2 making multiple requests when client cancels the load of the page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27884.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=27884
mod_jk2 making multiple requests when client cancels the load of the page
--- Additional Comments From [EMAIL PROTECTED] 2004-03-24 14:19 ---
I am using the release version 2.0.2 right now. Is there a binary version of
2.04 that I can download from someplace. I can test out if this fixes this
issue. From what I have seen of the 2.0.2 code, I felt that the following line
has an issue:
jk_worker_ajp13.c:
#define JK_RETRIES 2
static int JK_METHOD
jk2_worker_ajp13_forwardStream(jk_env_t *env, jk_worker_t *worker,
jk_ws_service_t *s,
jk_endpoint_t *e )
{
int err=JK_OK;
int attempt;
int has_post_body=JK_FALSE;
jk_channel_t *channel= worker-channel;
e-recoverable = JK_TRUE;
s-is_recoverable_error = JK_TRUE;
/*
* Try to send the request on a valid endpoint. If one endpoint
* fails, close the channel and try again ( maybe tomcat was restarted )
*
* XXX JK_RETRIES could be replaced by the number of workers in
* a load-balancing configuration
*/
for(attempt = 0 ; attempt JK_RETRIES ;attempt++) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 2.0.4 tagged
-Original Message- From: Henri Gomez Will you build the sources? I'm preparing a source tarball, and will build Linux binaries for Fedora Core 1, Suse 9.0 and Suse SLES 8.0 (PPC). Others archs, are welcomed Did we agreed on binary dist? What's gonna be the dir layout and files included? Can you write some guidelines? I'll build all the WIN32 executables, and can do FreeBSD 5.2.1 package. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27884] - mod_jk2 making multiple requests when client cancels the load of the page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27884. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27884 mod_jk2 making multiple requests when client cancels the load of the page [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 14:26 --- Thanks to check against latest JK 2.0.4 (tagged today), tarball in few hours and reopen if needed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 2.0.4 tagged
Mladen Turk wrote: -Original Message- From: Henri Gomez Will you build the sources? I'm preparing a source tarball, and will build Linux binaries for Fedora Core 1, Suse 9.0 and Suse SLES 8.0 (PPC). Others archs, are welcomed Did we agreed on binary dist? I was thinking providing something very similar to the one in jk 1.2.5, but we could still discuss. What's gonna be the dir layout and files included? Do you think at your proposal ? Why not Can you write some guidelines? The one proposed by Guenter ? ./apache2 /conf /workers2.properties.minimal /mod_jk2.conf /modules /mod_jk2.dll|nlm|so /ver-info /mod_jk2 /README /CHANGES /STATUS /INSTALL I'll build all the WIN32 executables, and can do FreeBSD 5.2.1 package. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 2.0.4 tagged
From: Henri Gomez [EMAIL PROTECTED] Mladen Turk wrote: -Original Message- From: Henri Gomez Will you build the sources? I'm preparing a source tarball, and will build Linux binaries for Fedora Core 1, Suse 9.0 and Suse SLES 8.0 (PPC). Others archs, are welcomed Did we agreed on binary dist? I was thinking providing something very similar to the one in jk 1.2.5, but we could still discuss. What's gonna be the dir layout and files included? Do you think at your proposal ? Why not Can you write some guidelines? The one proposed by Guenter ? ./apache2 /conf /workers2.properties.minimal /mod_jk2.conf /modules /mod_jk2.dll|nlm|so /ver-info /mod_jk2 /README /CHANGES /STATUS /INSTALL We should add LICENCE to the above list of files in /ver-info. I will do packages for OpenBSD/i386 3.4 and FreeBSD 4.9. I'd like to use the ports/package conventions of these OS's instead of the above directory structure. In general do we need one directory layout for all OS's? I'll build all the WIN32 executables, and can do FreeBSD 5.2.1 package. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 2.0.4 tagged
Henri Gomez wrote: jk2 2.0.4 has been tagged. jk2_2_0_4 We're now in HEAD at 2.0.5-dev Congratulations :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5] Two proposals.
Hi,
I would like to propose two modifications:
[1] XML Validation
I would like to make two changes to the way xml validation is implemented:
(1) make the attribute available at the context level (turned off by
default)
(2) add supports for turning on/off web.xml validation and tld
validation separately.
The host implementation will stay the same (the current one). This way
it will be possible to turn on/off validation of TLDs without impacting
performance (e.g.web.xml)
[2] Overridable list of javax packages in WebappClassloader.
Right now, the WebappClassloader.packageTriggers contains javax. I
guess this restriction comes from the J2EE specs, except that we should
allow users to override packages that start with javax but are *not*
included in J2EE (ex: JSF, JSTL). I would like to add a mechanism that
contains a list of overridable packages:
/**
* Adds the given package name to the list of packages that may
always be
* overriden, regardless of whether they belong to a protected
namespace
*/
public void addOverridablePackage(String packageName){
if (overridablePackages == null){
overridablePackages = new ArrayList();
}
overridablePackages.add(packageName);
}
and add in WebappClassloader.filter(...)
if (overridablePackages != null){
for (int i = 0; i overridablePackages.size(); i++) {
if (packageName.
startsWith((String)overridablePackages.get(i)))
return false;
}
}
and then either add an attribute in context.xml (or globally in
server.xml...I have no prefs). As an example, putting JSTL 1.0 under
common/lib and bundling JSTL 1.1 in WEB-INF/lib will possibly cause
problems, because the API starts with javax.servlet.jsp.jstl.*, and the
1.0 api will get loaded instead of 1.1 (I know , API are not supposed to
changes, but the reality is different :-) )
Comments?
Thanks,
-- Jeanfrancois
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk HOWTO-RELEASE
hgomez 2004/03/24 07:33:36 Modified:jk HOWTO-RELEASE Log: Add comments on zip Revision ChangesPath 1.10 +4 -0 jakarta-tomcat-connectors/jk/HOWTO-RELEASE Index: HOWTO-RELEASE === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/HOWTO-RELEASE,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- HOWTO-RELEASE 30 Sep 2003 11:38:59 - 1.9 +++ HOWTO-RELEASE 24 Mar 2004 15:33:36 - 1.10 @@ -154,6 +154,10 @@ tar zcf jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz jakarta-tomcat-connectors-jk-1.2.5-src +Create a zip archive + +zip -r jakarta-tomcat-connectors-jk-1.2.5-src.zip jakarta-tomcat-connectors-jk-1.2.5-src + Sign the release using PGP. Here is an example using gpg: gpg -abs -o jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz.asc jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.0.20 Issue
Jess Holle wrote: Works just great in quick testing at least. I'm still waiting for my precompilation script to return to determine whether Jasper still compiles everything it used to (and should have). Unfortunately, Tomcat 5.0.20 cannot compile 6 out our 985 JSP pages (which Tomcat 5.0.19 compiled just fine). The issue can be traced directly to a single entry in the change log: Add some intellignece to the compiler for generating code for useBean action. Generate direct instantiation (use new) when possible, use bean.instantiate when bean name is specified, and for the case of invalid bean class, either issue a translation time error (instead of javac error), or generate codes to throw InstantiationException at runtime, depending on a new compiler switch, errorOnUseBeanInvalidClassAttribute(defaulted to true) (kinman) There are several issues with this change: 1. The new logic assumes that the bean can be directly instantiated /at compile time/ and throws a page compilation error when this is not the case. * There are beans that can be directly instantiated at run time but not at compile time (e.g. upon precompilation). This was the case in all 6 of our failures. [Examples as to when this might occur include requirements for databases being accessible, other servers running, etc, etc, for successful bean instantiation.] * The error occurs in such a way that a partial Java source file is written, so later attempts to recompile the page (when the runtime environment is duplicated) also fail unless the partial Java source file is first deleted. 2. I note the errorOnUseBeanInvalidClassAttribute setting but there are issues here as well: * The default value, true, breaks existing code. * If errorOnUseBeanInvalidClassAttribute is set to false: o Instantiation of some (e.g. session or application scope) beans can be time and/or resource consuming. Besides being an invalid test as to whether a bean can be directly instantiated, instantiating such beans during compilation can be costly. [The combined time for precompiling all pages was longer in 5.0.20 with this behavior in place than when I removed it.] o The new behavior will cause beans to be instantiated via Beans.instantiate() rather than directly instantiated when compile time direct instantiation fails. This leads to a performance degradation whenever a bean has a runtime instantiation dependency. * As best I can tell, errorOnUseBeanInvalidClassAttribute is not accessible from / exposed via JspC main -- which I use from my pre-compilation scripts for various reasons. Due to these issues I have reverted this change in Generator to the 5.0.19 state (leaving the other valuable changes in this class intact). Once I did so all 985 JSP pages compiled -- including the 6 that had previously failed. I would urge that this change be reverted -- either in this release (or an immediate 5.0.21 release) or immediately changed in HEAD for the next release. -- Jess Holle
Re: Tomcat 5.0.20 Issue
Jess Holle wrote: Jess Holle wrote: Works just great in quick testing at least. I'm still waiting for my precompilation script to return to determine whether Jasper still compiles everything it used to (and should have). Unfortunately, Tomcat 5.0.20 cannot compile 6 out our 985 JSP pages (which Tomcat 5.0.19 compiled just fine). The issue can be traced directly to a single entry in the change log: Add some intellignece to the compiler for generating code for useBean action. Generate direct instantiation (use new) when possible, use bean.instantiate when bean name is specified, and for the case of invalid bean class, either issue a translation time error (instead of javac error), or generate codes to throw InstantiationException at runtime, depending on a new compiler switch, errorOnUseBeanInvalidClassAttribute(defaulted to true) (kinman) There are several issues with this change: 1. The new logic assumes that the bean can be directly instantiated /at compile time/ and throws a page compilation error when this is not the case. * There are beans that can be directly instantiated at run time but not at compile time (e.g. upon precompilation). This was the case in all 6 of our failures. [Examples as to when this might occur include requirements for databases being accessible, other servers running, etc, etc, for successful bean instantiation.] * The error occurs in such a way that a partial Java source file is written, so later attempts to recompile the page (when the runtime environment is duplicated) also fail unless the partial Java source file is first deleted. 2. I note the errorOnUseBeanInvalidClassAttribute setting but there are issues here as well: * The default value, true, breaks existing code. * If errorOnUseBeanInvalidClassAttribute is set to false: o Instantiation of some (e.g. session or application scope) beans can be time and/or resource consuming. Besides being an invalid test as to whether a bean can be directly instantiated, instantiating such beans during compilation can be costly. [The combined time for precompiling all pages was longer in 5.0.20 with this behavior in place than when I removed it.] o The new behavior will cause beans to be instantiated via Beans.instantiate() rather than directly instantiated when compile time direct instantiation fails. This leads to a performance degradation whenever a bean has a runtime instantiation dependency. * As best I can tell, errorOnUseBeanInvalidClassAttribute is not accessible from / exposed via JspC main -- which I use from my pre-compilation scripts for various reasons. Due to these issues I have reverted this change in Generator to the 5.0.19 state (leaving the other valuable changes in this class intact). Once I did so all 985 JSP pages compiled -- including the 6 that had previously failed. I would urge that this change be reverted -- either in this release (or an immediate 5.0.21 release) or immediately changed in HEAD for the next release. Well, your pages are invalid. Really, I don't see what's so mysterious: anything used in useBean must be a JavaBean. This will not be fixed. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.20 Issue
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26444 -Tim Jess Holle wrote: Jess Holle wrote: Unfortunately, Tomcat 5.0.20 cannot compile 6 out our 985 JSP pages (which Tomcat 5.0.19 compiled just fine). The issue can be traced directly to a single entry in the change log: Add some intellignece to the compiler for generating code for useBean action. Generate direct instantiation (use new) when possible, use bean.instantiate when bean name is specified, and for the case of invalid bean class, either issue a translation time error (instead of javac error), or generate codes to throw InstantiationException at runtime, depending on a new compiler switch, errorOnUseBeanInvalidClassAttribute(defaulted to true) (kinman) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] Two proposals.
Jeanfrancois Arcand wrote:
Hi,
I would like to propose two modifications:
[1] XML Validation
I would like to make two changes to the way xml validation is implemented:
(1) make the attribute available at the context level (turned off by
default)
(2) add supports for turning on/off web.xml validation and tld
validation separately.
The host implementation will stay the same (the current one). This way
it will be possible to turn on/off validation of TLDs without impacting
performance (e.g.web.xml)
Ah ok.
[2] Overridable list of javax packages in WebappClassloader.
Right now, the WebappClassloader.packageTriggers contains javax. I
guess this restriction comes from the J2EE specs, except that we should
allow users to override packages that start with javax but are *not*
included in J2EE (ex: JSF, JSTL). I would like to add a mechanism that
contains a list of overridable packages:
/**
* Adds the given package name to the list of packages that may
always be
* overriden, regardless of whether they belong to a protected
namespace
*/
public void addOverridablePackage(String packageName){
if (overridablePackages == null){
overridablePackages = new ArrayList();
}
overridablePackages.add(packageName);
}
and add in WebappClassloader.filter(...)
if (overridablePackages != null){
for (int i = 0; i overridablePackages.size(); i++) {
if (packageName.
startsWith((String)overridablePackages.get(i)))
return false;
}
}
and then either add an attribute in context.xml (or globally in
server.xml...I have no prefs). As an example, putting JSTL 1.0 under
common/lib and bundling JSTL 1.1 in WEB-INF/lib will possibly cause
problems, because the API starts with javax.servlet.jsp.jstl.*, and the
1.0 api will get loaded instead of 1.1 (I know , API are not supposed to
changes, but the reality is different :-) )
Comments?
Well, the second one wouldn't change many things. packageTrigger is
mostly useless right now, ever since I added delegate first to the
system classloader. Indeed, this would allow overriding specific stuff
like JSTL.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.20 Issue
Remy Maucherat wrote: Well, your pages are invalid. Really, I don't see what's so mysterious: anything used in useBean must be a JavaBean. This will not be fixed. Did I miss something? Are JavaBean default constructors required to succeed in any/all environments? Specifically are they required to succeed at compile time when none of the runtime requirements they have are met? This seems somewhat odd to say the least. That said, I did not author any of the beans in question and could certainly give the authors of said beans hell for their transgressions *IF* I have sufficient proof that what they're doing is completely wrong. Overall, however, the change in 5.0.20 still seems questionable -- at least with respect to the many other details (e.g. that the default causes new failures, that the compiler flag is not accessible via JspC.main(), etc...) -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.20 Issue
Based on the given bug id, I would propose a different implementation than that found in 5.0.20. Specifically I would suggest that Generator: 1. Try to load the given class. 2. Look up its default (no-args) constructor via reflection. [This is the key part, look up the constructor but don't call it!] 3. If a public no-args constructor IS found, then code should be generated to use it to directly instantiate the bean. 4. If a public no-args constructor is NOT found, then a page error should be generated and Beans.instantiate() should be used if errorOnUseBeanInvalidClassAttribute is set to false. This should be more efficient, avoid breaking pages using beans with non-trivial environmental constraints for successful construction, and follow the letter of the spec better as I see it. -- Jess Holle Tim Funk wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26444 -Tim Jess Holle wrote: Jess Holle wrote: Unfortunately, Tomcat 5.0.20 cannot compile 6 out our 985 JSP pages (which Tomcat 5.0.19 compiled just fine). The issue can be traced directly to a single entry in the change log: Add some intellignece to the compiler for generating code for useBean action. Generate direct instantiation (use new) when possible, use bean.instantiate when bean name is specified, and for the case of invalid bean class, either issue a translation time error (instead of javac error), or generate codes to throw InstantiationException at runtime, depending on a new compiler switch, errorOnUseBeanInvalidClassAttribute(defaulted to true) (kinman) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.20 Issue
P.S. Nothing in the quoted spec segments implies that the JSP compiler should attempt to actually *instantiate* beans at compile time or expect that that should work. -- Jess Holle Jess Holle wrote: Based on the given bug id, I would propose a different implementation than that found in 5.0.20. Specifically I would suggest that Generator: 1. Try to load the given class. 2. Look up its default (no-args) constructor via reflection. [This is the key part, look up the constructor but don't call it!] 3. If a public no-args constructor IS found, then code should be generated to use it to directly instantiate the bean. 4. If a public no-args constructor is NOT found, then a page error should be generated and Beans.instantiate() should be used if errorOnUseBeanInvalidClassAttribute is set to false. This should be more efficient, avoid breaking pages using beans with non-trivial environmental constraints for successful construction, and follow the letter of the spec better as I see it. -- Jess Holle Tim Funk wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26444 -Tim Jess Holle wrote: Jess Holle wrote: Unfortunately, Tomcat 5.0.20 cannot compile 6 out our 985 JSP pages (which Tomcat 5.0.19 compiled just fine). The issue can be traced directly to a single entry in the change log: Add some intellignece to the compiler for generating code for useBean action. Generate direct instantiation (use new) when possible, use bean.instantiate when bean name is specified, and for the case of invalid bean class, either issue a translation time error (instead of javac error), or generate codes to throw InstantiationException at runtime, depending on a new compiler switch, errorOnUseBeanInvalidClassAttribute(defaulted to true) (kinman) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Françoise Jégou/PAR/UPM is out of the office.
I will be out of the office starting 18/03/2004 and will not return until 29/03/2004. For hotel reservations in Paris pls contact Sandrine Robert/ Paris reception. Exceptionnaly, in case of difficulties with your Dial car, pls contact Nicolas Galle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Does Geronimo use tomcat?
Hi, However, I must warn you. Tomcat is not capable of being truly integrated into the Geronimo environment, because it does not use a componentized architectural style. Tomcat is very much an application, which can be bolted onto the side of Geronimo, but cannot be broken down and encapsulated into GBeans which are then able to be individually managed by the container. Believe me, I spent a month and a half researching the problem, and I did not arrive at this conclusion lightly. I believe you, and thanks for doing all this work ;) I'd like a list of things that are missing / problems you ran into / issues you want addressed in order to get tomcat embeddable within Geronimo. It's safe to say that's possible, as JBoss has been doing it for a while (and from some off-list discussions, I'm not alone in thinking that's a competitive advantage for JBoss over Geronimo at this stage). We also have many users who embed tomcat in their own apps, but as you say that doesn't necessarily reach the same manageability standard. No rush, but I'd like to see if we can help you from our side in making tomcat more Geronimo-friendly for lack of a better term. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27911] New: - Files being deleted by Tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27911. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27911 Files being deleted by Tomcat Summary: Files being deleted by Tomcat Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have deployed an application using Tomcat 4.1.24 release. After using the application for an amount of time. Tomcat is going into a mode where it starts to delete the files that Tomcat is trying to access. It is deleting any JSP or GIF files that I try to access within Tomcat. It is also deleting files from ROOT context and my application context. It is not deleting HTM and JPG files. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27911] - Files being deleted by Tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27911. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27911 Files being deleted by Tomcat [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 17:28 --- Obviously something else is causing this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27757] - Problem receiving data more than 3 KB.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27757. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27757 Problem receiving data more than 3 KB. [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 17:29 --- Upon upgrading and building TC 5.0.19 and Apache2.0.49, I discovered the problem in the proxy setting (bypass proxy server for local addresses was not used). Please accept my sincere apology for this mistake. Thank you very much for your time, effort and patience in helping us. Please consider this bug report solved and closed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Log4j classpath merging?
I'm using log4j to log application code for several websites, each of which has at least one WebApp, and some of which have more than one. I'm configuring log4j with an initialization servlet (that also does a few other things) from a properties file using .configureAndWatch(java.io.File). I'd like to allow each webapp to have its own log4j configuration. The typical configuration I am using logs to the console with the site name and webapp name prepended, logs a similar format to a RollingFileAppender with the file name determined by the site name, and a SMTPAppender for error notification. All of these are working fine, with one small exception... the configuration of the last properties file loaded is used for all debug output. For example, I am expecting to see: [www.domainname.com] log message [www.someothername.com] some other log message [www.athirddomain.com] yet another log message Instead, I'm seeing: [www.domainname.com] log message [www.domainname.com] some other log message [www.domainname.com] yet another log message I am using a large amount of common code across these webapps, so I can't just separate configurations by class name. Presently, I'm putting the log4j.jar file in the WEB-INF/lib for each webapp, and the properties file is in WEB-INF/properties (eg, not one of the standard log4j locations). I'm using log4j-1.2.8; I've seen this problem on both Tomcat 4.1.24 and 5.0.19. I found that when I put the log4j.properties file in WEB-INF/classes/log4j.properties it didn't seem to be found at all, which is why I moved to this method. I suspect that if the log4j code had already initialized itself from somewhere (perhaps for tomcat internal use?) it wouldn't need to look in specific webapp classpaths and thus wouldn't pick up the configuration. A bit of googling ran across the class below, which fixes the problem, except that you have to initialize log4j with that class, and you can only do so once; subsequent initializations (eg, with the same initializer servlet in multiple webapps) either throw ugly errors or could be easily overwritten by any webapp that disagreed with the idea and wanted to do something else. http://cvs.apache.org/viewcvs.cgi/jakarta-log4j-sandbox/src/java/org/apache/log4j/selector/ContextClassLoaderSelector.java?rev=1.7view=markup Since I had already written a Valve for something else and had sample code handy, I wrote a Valve to initialize log4j with a similar policy. This works and has solved my problem, but leaves me with three questions: 1) Is this the way it's supposed to work? (If so, someone should fix the log4j documentation). 2) If it's supposed to work this way, then it seems to me that setting the log4j policy to use separate heirarchies by classpath should be the default policy. I can't think of any reason why one webapp's logging configuration should be able to alter any other webapp's logging. Am I wrong? 3) If I'm right about 2, is there a better way to do it than a valve? Using a valve means I can drop the addition into an existing configuration, but it seems exceedingly awkward to run all requests through an extra layer just to get a class loaded and initialized once-and-only-once with no webapp dependencies. Is there a better construct for this sort of thing? 4) If there's interest I'd gladly contribute the valve to the apache codebase so others can just modify their server.xml rather than writing code; is there any interest in doing that? -- Matthew Hunter ([EMAIL PROTECTED]) Public Key: http://matthew.infodancer.org/public_key.txt Homepage: http://matthew.infodancer.org/index.jsp Politics: http://www.triggerfinger.org/index.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Mail Delivery (failure tomcat-dev@jakarta.apache.org)
** ** WARNING: WinProxy has detected a virus in file attached to this e-mail message! The attachment has been automatically removed to protect your network. WinProxy Administrator: [EMAIL PROTECTED] 03/24/04 12:06:17 WinProxy (Version 5.0 R1c (5.0.50.8)) - http://www.Ositis.com/ Antivirus Vendor: Panda Software Scan Engine Version: 2.10.1.6_3.1.5.211 Pattern File Version: 3.72094 (Timestamp: 2004/03/24 14:11:44) Machine name: Proxy Machine IP address: 216.201.132.30 Client: stm-tlaiig7ewv2 Protocol: SMTP Virus: Exploit/iFrame found! Attachment: No file name available ** ** ** ** WARNING: WinProxy has detected a prohibited file type attached to this e-mail message! The attachment has been automatically removed to protect your network. WinProxy Administrator: [EMAIL PROTECTED] 03/24/04 12:06:17 WinProxy (Version 5.0 R1c (5.0.50.8)) - http://www.Ositis.com/ Machine name: Proxy Machine IP address: 216.201.132.30 Client: stm-tlaiig7ewv2 Protocol: SMTP Attachment: message.scr ** **
DO NOT REPLY [Bug 16830] - Jasper do not reset BodyContent for tags with BodySupport and empty content
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=16830. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=16830 Jasper do not reset BodyContent for tags with BodySupport and empty content --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 18:38 --- BTW, issuing an extra setBodyContent to reset the bodyContent did break a TCK test, so it violates the current JSP 2.0 spec. Haven't run JSP 1.2 TCK tests yet, but I'll hate to have Tomcat 5 behaves differently from Tomcat 4. In any case, JSP 2.0 is supposed to clarify or fix problems in JSP 1.2, so if there are disagreements, we should go with JSP 2.0: you don't want to have to face the same problems again when porting to Tomcat 5 later! I did consult with Mark Roth, our resident JSP lead, and he suggested that Jasper NOT reuse the tag if the first tag has a body and second does not. I think this makes lots of sense and I'll fix Jasper to to so. Stay tuned. :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Mail Delivery (failure tomcat-dev@jakarta.apache.org)
** ** WARNING: WinProxy has detected a virus in file attached to this e-mail message! The attachment has been automatically removed to protect your network. WinProxy Administrator: [EMAIL PROTECTED] 03/24/04 12:46:07 WinProxy (Version 5.0 R1c (5.0.50.8)) - http://www.Ositis.com/ Antivirus Vendor: Panda Software Scan Engine Version: 2.10.1.6_3.1.5.211 Pattern File Version: 3.72094 (Timestamp: 2004/03/24 14:11:44) Machine name: Proxy Machine IP address: 216.201.132.30 Client: stm-tlaiig7ewv2 Protocol: SMTP Virus: Exploit/iFrame found! Attachment: No file name available ** ** ** ** WARNING: WinProxy has detected a prohibited file type attached to this e-mail message! The attachment has been automatically removed to protect your network. WinProxy Administrator: [EMAIL PROTECTED] 03/24/04 12:46:07 WinProxy (Version 5.0 R1c (5.0.50.8)) - http://www.Ositis.com/ Machine name: Proxy Machine IP address: 216.201.132.30 Client: stm-tlaiig7ewv2 Protocol: SMTP Attachment: message.scr ** **
DO NOT REPLY [Bug 27916] New: - context.xml in war appears to require a docBase
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27916. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27916 context.xml in war appears to require a docBase Summary: context.xml in war appears to require a docBase Product: Tomcat 5 Version: 5.0.19 Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The deployment documentation states that you can put a context.xml in the META- INF directory of your war file to specify Tomcat specific settings. However, whenever I put a context.xml in my war file that looks like this: Context path=/atd reloadable=true /Context I get an NPE (see below) after dropping this file in the webapps directory and starting Tomcat. If I set the docBase this doesn't happen. However it doesn't make sense to set the docBase since who knows where the war file will actually be deployed at. Shouldn't the attributes in the context.xml file I provide with my web app just be defaults while the other attributes come from the xml file in the conf/Catalina/localhost directory? Of course there isn't a context file in there the first time I start the server up, but then again there isn't one in there when I drop in a war file without a context.xml file and one is created with a correct docBase. SEVERE: End event threw exception java.lang.reflect.InvocationTargetException 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.commons.beanutils.MethodUtils.invokeMethod (MethodUtils.java:252) at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:256) at org.apache.commons.digester.Rule.end(Rule.java:276) at org.apache.commons.digester.Digester.endElement(Digester.java:1058) at org.apache.catalina.util.CatalinaDigester.endElement (CatalinaDigester.java:123) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement (Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher. dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument (Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse(Digester.java:1567) at org.apache.catalina.core.StandardHostDeployer.install (StandardHostDeployer.java:519) at org.apache.catalina.core.StandardHost.install(StandardHost.java:906) at org.apache.catalina.startup.HostConfig.deployDescriptors (HostConfig.java:527) at org.apache.catalina.startup.HostConfig.deployApps (HostConfig.java:472) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1008) at org.apache.catalina.startup.HostConfig.lifecycleEvent (HostConfig.java:394) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent (LifecycleSupport.java:166) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1134) at org.apache.catalina.core.StandardHost.start(StandardHost.java:832) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1126) at org.apache.catalina.core.StandardEngine.start (StandardEngine.java:521) at org.apache.catalina.core.StandardService.start (StandardService.java:519) at org.apache.catalina.core.StandardServer.start (StandardServer.java:2345) at org.apache.catalina.startup.Catalina.start(Catalina.java:594) 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.start(Bootstrap.java:297) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:398) Caused by: java.lang.NullPointerException at java.io.File.init(File.java:180) at
Tomcat 5's service.bat, etc.
The service.bat and tomcat.exe in Tomcat 5 have a number of issues as I see it: 1. The new tomcat.exe (aka procrun) does not seem to reliably route stdout and stderr to the specified files. * Compare JavaService (aka Tomcat 4.1.x's tomcat.exe) stdout and stderr treatment to procrun's. JavaService captures all the startup stdout as well as System.out.println's, etc. procrun does not. 2. Tomcat 5 does not include any documentation on how to use procrun (or even that tomcat.exe is procrun). 3. I have not managed to get procrun to target the server JVM (as opposed to the client) in any reliable fashion. * With JavaService this was achieved by targeting the appropriate jvm.dll. The procrun docs say the same thing is possible, but this does not work. 4. service.bat does not route as many arguments to procrun as what I for one route to JavaService -- and thus it provides less flexibility (especially with no documentation). * For JavaService I provide heap sizing, etc, parameters, as this is critical to any real use of Tomcat. * Having built in support for passing JPDA debug args to the JVM is also a must. 5. service.bat does not provide any default handling of tools.jar. * By default the resulting service can't compile JSP pages. Overall, service.bat and procrun feel like they're not ready for production use -- which is fine as long as that's understood by the user community. Personally, JavaService and an Ant script to produce the right (enormous) command line for seem to do the trick nicely -- with Tomcat 4.1.x and 5.0.x. -- Jess Holle
DO NOT REPLY [Bug 27917] New: - Error in action code
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27917. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27917 Error in action code Summary: Error in action code Product: Tomcat 5 Version: 5.0.19 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm seeing these messags on stdout: Mar 24, 2004 9:30:19 AM org.apache.jk.server.JkCoyoteHandler action SEVERE: Error in action code java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:489) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:697) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:487) at org.apache.coyote.Response.action(Response.java:226) at org.apache.coyote.Response.finish(Response.java:348) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:344) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:415) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:716) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:650) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:829) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:688) at java.lang.Thread.run(Thread.java:534) Does the code really need to report that the browser has dropped the connection? George - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 2.0.4 tagged
Is there a source tarball for 2.0.4 available for download somewhere yet? -- Jess Holle Henri Gomez wrote: jk2 2.0.4 has been tagged. jk2_2_0_4 We're now in HEAD at 2.0.5-dev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
We have Received your E-Mail
YOUR E-MAIL HAS BEEN RECEIVED BY ONEBEACON CUSTOMER SERVICE. YOU MAY EXPECT TO HAVE A RESPONSE WITHIN 24 HOURS. THANK YOU FOR WRITING US. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27916] - context.xml in war appears to require a docBase
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27916. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27916 context.xml in war appears to require a docBase [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 19:43 --- I'll eventually test this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27917] - Error in action code
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27917. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27917 Error in action code [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 19:46 --- This is not the place to ask questions. Do a google search on the topic or ask the question in [EMAIL PROTECTED] Thanks -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Building Jk2 isapi with VS.net Not working
I followed the instructions in the build.txt. I got the source for httpd and copied
the srclib over to
native2\srclib.
The instructions say to open the isapi.dsw. There is no dsw in the native2 directory
there but there is in the native directory.
under native2\server\isapi there is an isapi.dsp. I opened the dsp and fixed the
problems with the quotes around the ${input} params.
Now it complains about not being able to find the apr.h. Do I have to add some
reference to the project so that it knows where to find this apr? I was able to open
the apr project and build
apr.h shows up now in native2\srclib\apr\include
so I modified the includes directory to include everything that was needed from the
apache dirs
I also modified the linker to include the correct libs.
When I build and deploy IIS can't load the dll. Its not my configuration cause I can
replace the dll with the old one and it works fine. Something is wrong with the way I
am building.
Is there some way to define APACHE_HOME and how should I build apache?
Thanks,
Tim
Quick information on building mod_jk2 :
* IIS
There is a known issue with the latest APR 1.0 and MSVC6.
If you want to use MSVC6, please use APR 0.9.x for now.
MSVC7 doesn't have this issue, and could be used with APR 1.0.
Isapi redirector requires the following libraries to build:
apr, apr-util, apr-iconv and pcre.
The easiest way to obtain all those libraries is to download
the httpd-2.0.49-win32-src.zip from http://www.apache.org/dist/httpd or
from any of the mirror sites.
You will only need the srclib part (apr, apr-util, apr-iconv and pcre)
Unzip the entire srclib folder to j-t-c native2 folder.
Now open the isapi.dsw from MSVC6 and build.
Building using VS.NET:
Make sure that the required libraries are inside native2/srclib.
Open the idapi.dsw and select 'Yes to all' when prompted to convert the project.
During conversion the custom build adds extra quotations for
jk_logger_win32_message.mc. Right click on that file and select Properties.
For Custom Build Step remove all the quotations around ${InputDir}
and ${InputPath}.
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup ContextConfig.java TldConfig.java
jfarcand2004/03/24 12:00:22
Modified:catalina/src/share/org/apache/catalina Context.java
catalina/src/share/org/apache/catalina/core
StandardContext.java
catalina/src/share/org/apache/catalina/mbeans
MBeanFactory.java
catalina/src/share/org/apache/catalina/startup
ContextConfig.java TldConfig.java
Log:
Add support for xml validation/namespaceAware at the context level. The new
attributes override the ones set on the host element.
Add a dummy method for jmx calls (until the admin starts supporting the new sets
of attributes)
Revision ChangesPath
1.11 +69 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Context.java
Index: Context.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Context.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- Context.java 27 Feb 2004 14:58:38 - 1.10
+++ Context.java 24 Mar 2004 20:00:22 - 1.11
@@ -1128,4 +1128,72 @@
public void removeWrapperListener(String listener);
+/**
+ * Get the server.xml context attribute's xmlNamespaceAware.
+ * @return true if namespace awarenes is enabled.
+ *
+ */
+public boolean getXmlNamespaceAware();
+
+
+/**
+ * Get the server.xml context 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);
+/**
+ * Get the server.xml context attribute's xmlValidation.
+ * @return true if validation is enabled.
+ */
+
+
+/**
+ * Set the validation feature of the XML parser used when
+ * parsing tlds files.
+ * @param tldXmlValidation true to enable xml instance validation
+ */
+public void setTldValidation(boolean tldValidation);
+
+
+/**
+ * Get the server.xml context attribute's webXmlValidation.
+ * @return true if validation is enabled.
+ *
+ */
+public boolean getTldValidation();
+
+
+/**
+ * Get the server.xml host attribute's xmlNamespaceAware.
+ * @return true if namespace awarenes is enabled.
+ */
+public boolean getTldNamespaceAware();
+
+
+/**
+ * Set the namespace aware feature of the XML parser used when
+ * parsing xml instances.
+ * @param xmlNamespaceAware true to enable namespace awareness
+ */
+public void setTldNamespaceAware(boolean tldNamespaceAware);
+
+
}
+
1.121 +126 -8
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.120
retrieving revision 1.121
diff -u -r1.120 -r1.121
--- StandardContext.java 22 Mar 2004 12:45:55 - 1.120
+++ StandardContext.java 24 Mar 2004 20:00:22 - 1.121
@@ -575,12 +575,38 @@
private long startTime;
private long tldScanTime;
-/** Name of the engine. If null, the domain is used.
+/**
+ * Name of the engine. If null, the domain is used.
*/
private String engineName = null;
private String j2EEApplication=none;
private String j2EEServer=none;
+
+/**
+ * Attribute value used to turn on/off XML validation
+ */
+ private boolean webXmlValidation = false;
+
+
+/**
+ * Attribute value used to turn on/off XML namespace validation
+ */
+ private boolean webXmlNamespaceAware = false;
+
+
+/**
+ * Attribute value used to turn on/off XML validation
+ */
+ private boolean tldValidation = false;
+
+
+/**
+ * Attribute value used to turn on/off TLD XML namespace validation
+ */
+ private boolean tldNamespaceAware = false;
+
+
// - Context Properties
public void setName( String name ) {
@@ -4179,10 +4205,24 @@
// Read
DO NOT REPLY [Bug 27917] - Error in action code
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27917. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27917 Error in action code [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 20:07 --- I wasn't asking a question. I was reporting an exception being thrown by Tomcat. If the exception is not serious, it should not be reported. If it is serious it is a bug. By the way, a google searched doesn't reveal an answer, just a lot of questions as to why! George - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
kinman 2004/03/24 13:05:27
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
- FIx bugzilla 16830: bodyContent content not reset when a tag is reused.
Revision ChangesPath
1.227 +7 -2
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.226
retrieving revision 1.227
diff -u -r1.226 -r1.227
--- Generator.java23 Mar 2004 01:56:39 - 1.226
+++ Generator.java24 Mar 2004 21:05:26 - 1.227
@@ -231,7 +231,8 @@
createTagHandlerPoolName(
n.getPrefix(),
n.getLocalName(),
-n.getAttributes());
+n.getAttributes(),
+n.hasEmptyBody());
n.setTagHandlerPoolName(name);
if (!names.contains(name)) {
names.add(name);
@@ -249,7 +250,8 @@
private String createTagHandlerPoolName(
String prefix,
String shortName,
-Attributes attrs) {
+Attributes attrs,
+boolean hasEmptyBody) {
String poolName = null;
if (prefix.indexOf('-') = 0)
@@ -274,6 +276,9 @@
for (int i = 0; i attrNames.length; i++) {
poolName = poolName + _ + attrNames[i];
}
+}
+if (hasEmptyBody) {
+poolName = poolName + _nobody;
}
return poolName;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
kinman 2004/03/24 13:31:07
Modified:jasper2/src/share/org/apache/jasper/compiler Tag:
tomcat_4_branch Generator.java
Log:
-Fix 16830: bodyContent content not reset when a tag is reused.
Revision ChangesPath
No revision
No revision
1.35.2.22 +10 -5
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.35.2.21
retrieving revision 1.35.2.22
diff -u -r1.35.2.21 -r1.35.2.22
--- Generator.java5 Feb 2004 22:19:07 - 1.35.2.21
+++ Generator.java24 Mar 2004 21:31:07 - 1.35.2.22
@@ -195,7 +195,8 @@
String name = createTagHandlerPoolName(n.getPrefix(),
n.getShortName(),
-n.getAttributes());
+n.getAttributes(),
+ n.getBody() == null);
n.setTagHandlerPoolName(name);
if (!names.contains(name)) {
names.add(name);
@@ -212,7 +213,8 @@
*/
private String createTagHandlerPoolName(String prefix,
String shortName,
- Attributes attrs) {
+ Attributes attrs,
+boolean hasEmptyBody) {
String poolName = null;
if (prefix.indexOf('-') = 0)
@@ -238,6 +240,9 @@
poolName = poolName + _ + attrNames[i];
}
}
+if (hasEmptyBody) {
+poolName = poolName + _nobody;
+}
return poolName;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5's service.bat, etc.
- Original Message - From: Jess Holle [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, March 24, 2004 11:18 AM Subject: Tomcat 5's service.bat, etc. The service.bat and tomcat.exe in Tomcat 5 have a number of issues as I see it: 1. The new tomcat.exe (aka procrun) does not seem to reliably route stdout and stderr to the specified files. * Compare JavaService (aka Tomcat 4.1.x's tomcat.exe) stdout and stderr treatment to procrun's. JavaService captures all the startup stdout as well as System.out.println's, etc. procrun does not. Procrun works fine with --Java=java. Yes, it needs work for --Java=c:\path\to\jvm.dll (known issue, with outstanding BZ entry :). 2. Tomcat 5 does not include any documentation on how to use procrun (or even that tomcat.exe is procrun). 3. I have not managed to get procrun to target the server JVM (as opposed to the client) in any reliable fashion. * With JavaService this was achieved by targeting the appropriate jvm.dll. The procrun docs say the same thing is possible, but this does not work. This works fine for me with either --Java=java -JavaOptions=-server#... or with --Java=c:\path\to\server\jvm.dll. 4. service.bat does not route as many arguments to procrun as what I for one route to JavaService -- and thus it provides less flexibility (especially with no documentation). * For JavaService I provide heap sizing, etc, parameters, as this is critical to any real use of Tomcat. * Having built in support for passing JPDA debug args to the JVM is also a must. So edit the service.bat file :). As usual, patches are always welcome ;-). 5. service.bat does not provide any default handling of tools.jar. * By default the resulting service can't compile JSP pages. Overall, service.bat and procrun feel like they're not ready for production use -- which is fine as long as that's understood by the user community. Personally, JavaService and an Ant script to produce the right (enormous) command line for seem to do the trick nicely -- with Tomcat 4.1.x and 5.0.x. Whatever makes you happy ;-). -- Jess Holle This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16830] - Jasper do not reset BodyContent for tags with BodySupport and empty content
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=16830. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=16830 Jasper do not reset BodyContent for tags with BodySupport and empty content [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 21:49 --- I have fixed Jasper (both Tomcat 4 and 5) to not reuse tags in this case. It should be in the next release. So for tag:myBody content=true this is inside myBody tag /tagmyBody tag:myBody content=true / tag:myBody content=false this is inside myBody tag /tag:myBody the second tag would now has a null bodyContent, since it is not reusing the tag instance from the first, but the 3rd tag would reuse the tag instance from the first, and the bodyContent would not be reset, because doStartTag returns a SKIP_BODY. I consider it an user error to try getting its bodyContent when doStartTag returns a SKIP_BODY. This is the best I can do to fix this problem and still be spec-conformant. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Coyote's ServerSocketFactory problem
Hello Tomcat Developers! I'm working with Tomcat 4.1.29 and I'd like to use my own ServerSocketFactory, as I'm working on a custom implementation of httpg (HTTP over GSSAPI authenticated sockets). This seems impossible by design, which I think may be a bug. Instead of using the deprecated HttpConnector I'm trying to use the CoyoteConnector. The trouble is, with CoyoteConnector there is no way to override the ServerSocketFactory to be used. My CustomServerSocketFactory implements org.apache.catalina.net.ServerSocketFactory, and I tried using the following in server.xml: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=6688 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=100 debug=50 connectionTimeout=2 scheme=httpg useURIValidationHack=false disableUploadTimeout=true Factory className=my.own.CustomServerSocketFactory principal=service/[EMAIL PROTECTED] keytab=/etc/keytab / /Connector This will successfully set the factory in CoyoteConnector, but it does NOT propagate to org.apache.coyote.http11.Http11Protocol, and the actual factory getting used at runtime is the default one in Http11Protocol. The CoyoteConnector's factory datamember is totally ignored. I would think that in org/apache/coyote/tomcat4/CoyoteConnector.java around lines -1135 there should be something to propagate the socket factory to the protocolHandler. However even then, Http11Protocol insists on using org.apache.tomcat.util.net.ServerSocketFactory, not the org.apache.catalina.net.ServerSocketFactory required by the CoyoteConnector. (?) Bottom line - how is one supposed to specify a custom ServerSocketFactory with the CoyoteConnector? Bill Barker has emailed me a suggestion of using the socketFactory=fully.qualified.name.of.MyOwnServerSocketFactory attribute on the Connector element. While I appreciate the response, that doesn't set the factory datamember in the Connector, and neither does it change the socketFactory in the protocolHandler. I appreciate your help on this -anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18489] - thread leak in deploy war package
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=18489. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=18489 thread leak in deploy war package [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 22:21 --- Just tested this with the latest source from CVS (4.1.30 plus fixes) and I do not see any permanent increase in threads. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5's service.bat, etc.
Bill Barker wrote: The service.bat and tomcat.exe in Tomcat 5 have a number of issues as I see it: 1. The new tomcat.exe (aka procrun) does not seem to reliably route stdout and stderr to the specified files. * Compare JavaService (aka Tomcat 4.1.x's tomcat.exe) stdout and stderr treatment to procrun's. JavaService captures all the startup stdout as well as System.out.println's, etc. procrun does not. Procrun works fine with --Java=java. Yes, it needs work for --Java=c:\path\to\jvm.dll (known issue, with outstanding BZ entry :). Hmmm --Java=pathToJvmDll did not work at all for me -- service failed to install and other errors. [W2K with latest service packs and Java 2 v1.4.2_04.] --Java=java worked but lost most of the stdout and stderr output -- including all the startup output. It did seem to start up faster than JavaService... 2. Tomcat 5 does not include any documentation on how to use procrun (or even that tomcat.exe is procrun). 3. I have not managed to get procrun to target the server JVM (as opposed to the client) in any reliable fashion. * With JavaService this was achieved by targeting the appropriate jvm.dll. The procrun docs say the same thing is possible, but this does not work. This works fine for me with either --Java=java -JavaOptions=-server#... or with --Java=c:\path\to\server\jvm.dll. I was actually referring to the latter approach, which as I said did not work for me. I did not honestly trust the first approach -- I guess I should have 4. service.bat does not route as many arguments to procrun as what I for one route to JavaService -- and thus it provides less flexibility (especially with no documentation). * For JavaService I provide heap sizing, etc, parameters, as this is critical to any real use of Tomcat. * Having built in support for passing JPDA debug args to the JVM is also a must. So edit the service.bat file :). As usual, patches are always welcome ;-). The fact that you have to replace all spaces with #'s and shovel all JAVA_OPTS or CATALINA_OPTS into a single argument makes it more difficult to just pass in and concatenate portions of the command line. With JavaService, one can do: set javaMemArgs=... set debugArgs=... set javaPropArgs=... set javaArgs=%javaMemArgs% %debugArgs% %javaPropArgs% JavaService.exe -install %serviceName% %jvmDllArg% %javaArgs% %startArgs% %stopArgs% %stdioArgs% %currDirArgs% In other words, one can flexibly and easily insert additional arguments. With procrun, I have to worry about replacing some spaces with #'s, properly escaping quotes, etc, within the aggregate argument containing all the Java arguments, etc. Essentially this makes it harder to have a one-size fits (most) all script. 5. service.bat does not provide any default handling of tools.jar. * By default the resulting service can't compile JSP pages. Overall, service.bat and procrun feel like they're not ready for production use -- which is fine as long as that's understood by the user community. I should clarify that another reason for this was a number of crashes I had just installing and removing my service with procrun. -- Jess Holle
Re: Tomcat 5.0.20 Issue
I think your only valid point is the one about the need to make errorOnUseBeanInvalidClassAttribute be switchable from Jspc main, but we are not bundling jspc scripts anymore, so I didn't feel there is a need for it. Anyway, its value can be set with an ant task. Otherwise, Jasper behaves the same as before when errorOnUseBeanInvalidClassAttribute is set to false. Well, maybe it take more time to compile, but that's a compile-time vs. runt-time tradeoff that all compilers make. The ideas behind the fix, both in the Jasper and the JSP 2.0 spec, is to allow the Jasper to generate faster code and to catch as much errors as possible at compile time. For the embedded compilations, the comile environment is the same as the runitme (request time) environment, so there is no problem. For Jspc compilations, you'll just need to make sure that they are the same, otherwise you'll need to set errorOnUseBeanInvalidClassAttribute to false there. If you have ideas about how to modify Generator that works better, please submit a patch, and I'll see if it can be incorporated. -Kin-man Date: Wed, 24 Mar 2004 09:50:43 -0600 From: Jess Holle [EMAIL PROTECTED] Subject: Tomcat 5.0.20 Issue To: Tomcat Developers List [EMAIL PROTECTED] X-OriginalArrivalTime: 24 Mar 2004 15:50:43.0599 (UTC) FILETIME=[C3DDB1F0:01C411B7] Jess Holle wrote: Works just great in quick testing at least. I'm still waiting for my precompilation script to return to determine whether Jasper still compiles everything it used to (and should have). Unfortunately, Tomcat 5.0.20 cannot compile 6 out our 985 JSP pages (which Tomcat 5.0.19 compiled just fine). The issue can be traced directly to a single entry in the change log: Add some intellignece to the compiler for generating code for useBean action. Generate direct instantiation (use new) when possible, use bean.instantiate when bean name is specified, and for the case of invalid bean class, either issue a translation time error (instead of javac error), or generate codes to throw InstantiationException at runtime, depending on a new compiler switch, errorOnUseBeanInvalidClassAttribute(defaulted to true) (kinman) There are several issues with this change: 1. The new logic assumes that the bean can be directly instantiated /at compile time/ and throws a page compilation error when this is not the case. * There are beans that can be directly instantiated at run time but not at compile time (e.g. upon precompilation). This was the case in all 6 of our failures. [Examples as to when this might occur include requirements for databases being accessible, other servers running, etc, etc, for successful bean instantiation.] * The error occurs in such a way that a partial Java source file is written, so later attempts to recompile the page (when the runtime environment is duplicated) also fail unless the partial Java source file is first deleted. 2. I note the errorOnUseBeanInvalidClassAttribute setting but there are issues here as well: * The default value, true, breaks existing code. * If errorOnUseBeanInvalidClassAttribute is set to false: o Instantiation of some (e.g. session or application scope) beans can be time and/or resource consuming. Besides being an invalid test as to whether a bean can be directly instantiated, instantiating such beans during compilation can be costly. [The combined time for precompiling all pages was longer in 5.0.20 with this behavior in place than when I removed it.] o The new behavior will cause beans to be instantiated via Beans.instantiate() rather than directly instantiated when compile time direct instantiation fails. This leads to a performance degradation whenever a bean has a runtime instantiation dependency. * As best I can tell, errorOnUseBeanInvalidClassAttribute is not accessible from / exposed via JspC main -- which I use from my pre-compilation scripts for various reasons. Due to these issues I have reverted this change in Generator to the 5.0.19 state (leaving the other valuable changes in this class intact). Once I did so all 985 JSP pages compiled -- including the 6 that had previously failed. I would urge that this change be reverted -- either in this release (or an immediate 5.0.21 release) or immediately changed in HEAD for the next release. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27925] New: - getContext() fails for xml-specified contexts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27925.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=27925
getContext() fails for xml-specified contexts
Summary: getContext() fails for xml-specified contexts
Product: Tomcat 5
Version: 5.0.19
Platform: Other
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
If you run with crosscontext enabled:
%
javax.servlet.ServletContext context =
pageContext.getServletContext().getContext(/jsp-examples/cal/);
if (null!= context)
{
out.print(context.getRealPath(/));
}
%
Fine, result is:
D:\java\jakarta-tomcat-5.0.19\webapps\jsp-examples\
If you call getContext(/anothercontext);
it still works if /anothercontext is included with a context.xml file in
D:\java\jakarta-tomcat-5.0.19\conf\Catalina\localhost
But getContext(/anothercontext/) i.e. the slash or any existing path appended
results in D:\java\jakarta-tomcat-5.0.19\webapps\ROOT\
It seems the context-lookup algorithm checks only the part specified with
Context path=/anothercontext in the xml file.
But getContext() should find a context, regardless how the context is made known
to the container.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27925] - getContext() fails for xml-specified contexts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27925. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27925 getContext() fails for xml-specified contexts [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-03-24 23:24 --- Obviously not. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coyote's ServerSocketFactory problem
We have a similar need (though for a different reason) and extend CoyoteServerSocketFactory. We're running TC 4.1.29. Here's our Connector element: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=7002 scheme=https secure=true address=127.0.0.1 enableLookups=false Factory className=nyw.catalina.NYWCoyoteServerSocketFactory clientAuth=true/ /Connector Works great. -Jim Anton Ushakov wrote: Hello Tomcat Developers! I'm working with Tomcat 4.1.29 and I'd like to use my own ServerSocketFactory, as I'm working on a custom implementation of httpg (HTTP over GSSAPI authenticated sockets). This seems impossible by design, which I think may be a bug. Instead of using the deprecated HttpConnector I'm trying to use the CoyoteConnector. The trouble is, with CoyoteConnector there is no way to override the ServerSocketFactory to be used. My CustomServerSocketFactory implements org.apache.catalina.net.ServerSocketFactory, and I tried using the following in server.xml: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=6688 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=100 debug=50 connectionTimeout=2 scheme=httpg useURIValidationHack=false disableUploadTimeout=true Factory className=my.own.CustomServerSocketFactory principal=service/[EMAIL PROTECTED] keytab=/etc/keytab / /Connector This will successfully set the factory in CoyoteConnector, but it does NOT propagate to org.apache.coyote.http11.Http11Protocol, and the actual factory getting used at runtime is the default one in Http11Protocol. The CoyoteConnector's factory datamember is totally ignored. I would think that in org/apache/coyote/tomcat4/CoyoteConnector.java around lines -1135 there should be something to propagate the socket factory to the protocolHandler. However even then, Http11Protocol insists on using org.apache.tomcat.util.net.ServerSocketFactory, not the org.apache.catalina.net.ServerSocketFactory required by the CoyoteConnector. (?) Bottom line - how is one supposed to specify a custom ServerSocketFactory with the CoyoteConnector? Bill Barker has emailed me a suggestion of using the socketFactory=fully.qualified.name.of.MyOwnServerSocketFactory attribute on the Connector element. While I appreciate the response, that doesn't set the factory datamember in the Connector, and neither does it change the socketFactory in the protocolHandler. I appreciate your help on this -anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20380] - AccessLogValve incorrectly calculates timezone
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=20380. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=20380 AccessLogValve incorrectly calculates timezone [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Status|RESOLVED|REOPENED Resolution|FIXED | Version|4.1.24 |4.1.30 --- Additional Comments From [EMAIL PROTECTED] 2004-03-25 01:07 --- The offset still appears to be incorrect, though for a different reason that that originally reported: the timezone offset output does not include daylight saving. At the moment: x.x.x.x - - [25/Mar/2004:10:17:07 +0930] GET / HTTP/1.1 304 - should be reported as: x.x.x.x - - [25/Mar/2004:10:17:07 +1030] GET / HTTP/1.1 304 - Looking at org.apache.catalina.valves.AccessLogValve (4.1.30), line 1128 is: timeZone = calculateTimeZoneOffset(tz.getRawOffset()); I think this should use the TimeZone.getOffset() method instead, which returns the offset including DST. AFAICS from the CVS history the getRawOffset() method has always been used. Considering the length of time this has been in the source, either (a) I'm wrong, or (b) few people care. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coyote's ServerSocketFactory problem
In CoyoteConnector.initialize() there's an assumption that if the factory is an instance of CoyoteServerSocketFactory, it's gonna be SSL, and it sets secure=true. Then in Http11ConnectionHandler.checkSocketFactory() in the Http11Protocol.java, it interprets that secure flag as SSL and uses SSLImplementation to get the socket factory. In our case, the scheme is not ssl, so unfortunately this doesn't work. Http11Protocol just wasn't written to accept a socket factory object, and the one it makes from the passed classname is of a different type than CoyoteConnector's socket factory. It's not enough to make the types the same, it really should take a whole factory object, since the factory's attributes need to be set from the conf. On Wed, 2004-03-24 at 16:03, Jim Hopp wrote: We have a similar need (though for a different reason) and extend CoyoteServerSocketFactory. We're running TC 4.1.29. Here's our Connector element: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=7002 scheme=https secure=true address=127.0.0.1 enableLookups=false Factory className=nyw.catalina.NYWCoyoteServerSocketFactory clientAuth=true/ /Connector Works great. -Jim Anton Ushakov wrote: Hello Tomcat Developers! I'm working with Tomcat 4.1.29 and I'd like to use my own ServerSocketFactory, as I'm working on a custom implementation of httpg (HTTP over GSSAPI authenticated sockets). This seems impossible by design, which I think may be a bug. Instead of using the deprecated HttpConnector I'm trying to use the CoyoteConnector. The trouble is, with CoyoteConnector there is no way to override the ServerSocketFactory to be used. My CustomServerSocketFactory implements org.apache.catalina.net.ServerSocketFactory, and I tried using the following in server.xml: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=6688 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=100 debug=50 connectionTimeout=2 scheme=httpg useURIValidationHack=false disableUploadTimeout=true Factory className=my.own.CustomServerSocketFactory principal=service/[EMAIL PROTECTED] keytab=/etc/keytab / /Connector This will successfully set the factory in CoyoteConnector, but it does NOT propagate to org.apache.coyote.http11.Http11Protocol, and the actual factory getting used at runtime is the default one in Http11Protocol. The CoyoteConnector's factory datamember is totally ignored. I would think that in org/apache/coyote/tomcat4/CoyoteConnector.java around lines -1135 there should be something to propagate the socket factory to the protocolHandler. However even then, Http11Protocol insists on using org.apache.tomcat.util.net.ServerSocketFactory, not the org.apache.catalina.net.ServerSocketFactory required by the CoyoteConnector. (?) Bottom line - how is one supposed to specify a custom ServerSocketFactory with the CoyoteConnector? Bill Barker has emailed me a suggestion of using the socketFactory=fully.qualified.name.of.MyOwnServerSocketFactory attribute on the Connector element. While I appreciate the response, that doesn't set the factory datamember in the Connector, and neither does it change the socketFactory in the protocolHandler. I appreciate your help on this -anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27917] - Error in action code
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27917. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27917 Error in action code [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkCoyoteHandler.java
billbarker2004/03/24 19:01:21
Modified:jk/java/org/apache/jk/server JkCoyoteHandler.java
Log:
Make certain that the endpoint is closed, even if Apache has already dropped the
connection.
IOExceptions here are pretty harmless, since they mean that Apache has already
finished with the page, and so doesn't need to be told that the page is done.
Fix for Bug #27917.
Revision ChangesPath
1.53 +12 -9
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java
Index: JkCoyoteHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -r1.52 -r1.53
--- JkCoyoteHandler.java 24 Feb 2004 08:48:41 - 1.52
+++ JkCoyoteHandler.java 25 Mar 2004 03:01:21 - 1.53
@@ -173,7 +173,7 @@
jkInputStream);
} catch( Exception ex ) {
-ex.printStackTrace();
+log.error(Error during init,ex);
}
}
@@ -189,7 +189,7 @@
}
getJkMain().start();
} catch( Exception ex ) {
-ex.printStackTrace();
+log.error(Error during startup,ex);
}
}
@@ -295,7 +295,7 @@
try {
adapter.service( req, res );
} catch( Exception ex ) {
-ex.printStackTrace();
+log.info(Error servicing request + req,ex);
}
if(ep.getStatus() != JK_STATUS_CLOSED) {
res.finish();
@@ -439,13 +439,16 @@
msg.reset();
msg.appendByte( HandlerRequest.JK_AJP13_END_RESPONSE );
msg.appendByte( 1 );
-
-ep.setType( JkHandler.HANDLE_SEND_PACKET );
-ep.getSource().invoke( msg, ep );
-
-ep.setType( JkHandler.HANDLE_FLUSH );
-ep.getSource().invoke( msg, ep );
+try {
+ep.setType( JkHandler.HANDLE_SEND_PACKET );
+ep.getSource().invoke( msg, ep );
+
+ep.setType( JkHandler.HANDLE_FLUSH );
+ep.getSource().invoke( msg, ep );
+} catch(IOException iex) {
+log.debug(Connection error ending request.,iex);
+}
ep.setStatus(JK_STATUS_CLOSED );
if( logTime.isDebugEnabled() )
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27917] - Error in action code
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27917. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27917 Error in action code --- Additional Comments From [EMAIL PROTECTED] 2004-03-25 03:04 --- Yeah, well, despite the fact that this bug is resolved WONTFIX, it is now fixed in the CVS ;-). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
En réponse à votre demande de soutien technique - IMPORTANT
Merci d'avoir fait parvenir un courriel à [EMAIL PROTECTED] Toutefois, cette adresse courriel n'est plus surveillée. Veuillez cliquer sur le lien suivant http://www.intuitgreenpoint.com/SupportQuestions/support.dll/ http://www.intuitgreenpoint.com/SupportQuestions/support.dll/ http://www.intuitgreenpoint.com/SupportQuestions/support.dll/FQuestion FQuestion (ou copiez-le dans votre fureteur Internet) pour remplir notre formulaire de Soutien technique par courriel et nous aider à compléter votre demande plus rapidement et avec plus d'efficacité. Selon les informations que vous fournirez, vous verrez une liste immédiate de réponses possibles à votre question. Si aucune de ces solutions ne résout votre problème, vous pourrez alors envoyer un courriel à notre équipe de Soutien technique. Votre demande sera immédiatement acheminée à un agent qui s'y connaît dans le domaine qui vous préoccupe. Nous espérons que vous trouverez que ce nouvel outil vous permettra de résoudre vos problèmes plus rapidement. Nous souhaitons porter à votre attention que vous ne recevrez pas de réponse si vous répondez directement à ce courriel. Meilleures salutations, L'équipe de Soutien technique de Intuit Greenpoint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
