DO NOT REPLY [Bug 28123] - ClientAbortException should default to the description of the wrapped exception
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=28123. 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=28123 ClientAbortException should default to the description of the wrapped exception --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 23:56 --- Actually, ClientAbortException.toString will print out the root-cause exception. This means that your specific example above will work fine. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coyote's ServerSocketFactory problem
- Original Message - From: Anton Ushakov [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, April 02, 2004 10:46 AM Subject: Re: Coyote's ServerSocketFactory problem First I must say you've been extremely helpful, thank you for your prompt responses! I hate to bug you but I had another implementation question. I looked at JSSESocketFactory and how SSL is done in the connector, but it doesnt address one particular issue I'm having. Basically I have JAAS (GSSAPI) authentication done inside the Socket that my SocketFactory makes. Let's call it GssSocket, and it uses GssInputStream GssOutputStream for the authenticated encrypted communication. Inside the GssSocket I establish the identity (principal) of the incoming request, but have no way to set it into the CoyoteRequest so it can get passed to the target Servlets through the HttpServletRequest. Since all the servlet sees is the CoyoteRequestFacade, I cannot get access to either the GssSocket, or the GssStreams - the only places where the principal of the user is known. It looks like I can't avoid extending one of the Coyote classes after all. What would you suggest to override to be able to extract a string from the Socket and set it as an attribute for the servlets to get at? I'm sorry if this is getting too hairy, but any advice would be great. It's probably possible to do what you want without much, if any, modifying of Tomcat code. If you were to setup a full SSLImplementation to implement your socket factory, then you could have your code return the identity information in response to 'request.getAttribute(org.apache.coyote.request.X509Certificate)'. This should work because nothing in Tomcat outside of the SSLImplementation understands anything about SSL, so it won't really care that you aren't implementing real SSL. This method is a little hackish, but it has the advantage that you don't have to modify any of Tomcat's code to get it to work. The downside is that you have to implement a minimum of three classes, even if you can make most of the methods to be dummies. You'd also need to worry about the scheme getting set to https, but I could be talked into modifying that. Otherwise, you'd probably have to modify Http11Processor (about the only class that has access to both the Request and the Socket :) to set the attributes you want on the Request. thanks -anton On Thu, 2004-04-01 at 13:32, Bill Barker wrote: - Original Message - From: Anton Ushakov [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, March 31, 2004 10:59 PM Subject: Re: Coyote's ServerSocketFactory problem Alright, thanks Bill. I have nothing against Tomcat5 and indeed the socketFactory=my.factory attribute works. But is there any way to pass custom parameters to the factory from the conf file? With a Factory element it was possible but with a single attribute am I out of luck? All this IntrospectionUtils business is confusing... The way this works is that all of the Connector attributes are passed on to the Protocol. In the case of the Http11Protocol, the attributes are then passed on to the SocketFactory (via calling the setAttribute method of o.a.t.u.net.ServerSocketFactory). So all you have to do is to set your parameters on the Connector, and they will end up passed to your SocketFactory. You can look at JSSESocketFactory to see how Tomcat handles this for the default SSL connector. On Fri, 2004-03-26 at 18:03, Bill Barker wrote: - Original Message - From: Anton Ushakov [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, March 26, 2004 4:24 PM Subject: Re: Coyote's ServerSocketFactory problem Should I make a bug entry for this? I wanted to get someone from the tomcat dev team to see if I was missing something before flagging this as a bug. The Catalina SocketFactory is deprecated for use with Coyote in 5.x, and it would probably should be for 4.x as well except for the fact that it is still required to set SSL attributes. This means that anything involving this SocketFactory will just get marked as WONTFIX. Passing the socketFactory attribute on to the Protocol might be something (except for the fact that it is working in 5.x means it may not get a lot of attention :). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ 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
Notify about your e-mail account utilization.
attachment: qugoyyllkl.bmp- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15278] - [PATCH] mod_jk2 for IIS, Bugfix corrupted data ]
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=15278. 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=15278 [PATCH] mod_jk2 for IIS, Bugfix corrupted data ] [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2004-04-03 05:59 --- Ok, You've convince me. If I build a fixed binary will you be willing to test? Since I cannot reproduce the bug the testing will be on your side of the wire. Also the future correspondance should go trough standard TC dev list. Please subscribe if not. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15278] - [PATCH] mod_jk2 for IIS, Bugfix corrupted data ]
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=15278. 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=15278 [PATCH] mod_jk2 for IIS, Bugfix corrupted data ] --- Additional Comments From [EMAIL PROTECTED] 2004-04-03 06:28 --- Yes i will be willing to help with the test. I can install the version on the dev server which is IIS 5.0 with TC 5.0 and W2K and use these same machines to do the test. As of the email issue, I am subscribed but i get way too many emails i can't read them all. the bug report is very good because I am cc ed and i get the email in my inbox rather than the TC folder. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_service_iis.c
mturk 2004/04/02 22:47:23
Modified:jk/native2/server/isapi jk_service_iis.c
Log:
Read from client in the loop until all the requested data is read or timeout
occurs. This fixes random errors during read large post data.
Revision ChangesPath
1.30 +19 -11
jakarta-tomcat-connectors/jk/native2/server/isapi/jk_service_iis.c
Index: jk_service_iis.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/jk_service_iis.c,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- jk_service_iis.c 21 Mar 2004 09:45:16 - 1.29
+++ jk_service_iis.c 3 Apr 2004 06:47:23 - 1.30
@@ -156,6 +156,7 @@
if ((DWORD) s-content_read lpEcb-cbTotalBytes) {
DWORD rdlen, toread = len;
+DWORD cblen = 0;
LPBYTE buff = (LPBYTE) b;
/*
@@ -199,19 +200,26 @@
/*
* Now try to read from the client ...
*/
-if (lpEcb-ReadClient(lpEcb-ConnID, buff, rdlen)) {
-*actually_read += rdlen;
-env-l-jkLog(env, env-l, JK_LOG_DEBUG,
- jk_ws_service_t::read ReadClient readed %d (actually
%d) bytes\n,
- rdlen, *actually_read);
+
+while (cblen rdlen) {
+toread = rdlen - cblen;
+if (lpEcb-ReadClient(lpEcb-ConnID, buff + cblen, toread)) {
+if (toread == 0)
+break;
+cblen += toread;
+env-l-jkLog(env, env-l, JK_LOG_DEBUG,
+ jk_ws_service_t::read ReadClient readed %d
(actually %d) bytes\n,
+ toread, *actually_read + cblen);
+}
+else {
+env-l-jkLog(env, env-l, JK_LOG_ERROR,
+ jk_ws_service_t::read, ReadClient failed\n);
+/* XXX: We should return here HSE_STATUS_ERROR */
+break;
+}
}
-else {
-env-l-jkLog(env, env-l, JK_LOG_ERROR,
- jk_ws_service_t::read, ReadClient failed\n);
-/* XXX: We should return here HSE_STATUS_ERROR */
-return JK_OK;
-}
+*actually_read += cblen;
}
env-l-jkLog(env, env-l, JK_LOG_DEBUG,
jk_ws_service_t::read actually readed %d from already %d of
total %d bytes\n,
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/compat JdkCompat.java
billbarker2004/04/02 22:47:24
Modified:util/java/org/apache/tomcat/util/compat JdkCompat.java
Log:
Add detection for JDK 1.5
Revision ChangesPath
1.12 +9 -0
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/compat/JdkCompat.java
Index: JdkCompat.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/compat/JdkCompat.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- JdkCompat.java24 Feb 2004 08:50:05 - 1.11
+++ JdkCompat.java3 Apr 2004 06:47:24 - 1.12
@@ -66,6 +66,10 @@
return java14;
}
+public static boolean isJava15() {
+return java15;
+}
+
// Implementation
// from ant
@@ -74,10 +78,12 @@
public static final String JAVA_1_2 = 1.2;
public static final String JAVA_1_3 = 1.3;
public static final String JAVA_1_4 = 1.4;
+public static final String JAVA_1_5 = 1.5;
static String javaVersion;
static boolean java2=false;
static boolean java14=false;
+static boolean java15=false;
static JdkCompat jdkCompat;
static {
@@ -97,6 +103,9 @@
Class.forName(java.lang.CharSequence);
javaVersion = JAVA_1_4;
java14=true;
+Class.forName(java.lang.Appendable);
+javaVersion = JAVA_1_5;
+java15=true;
} catch (ClassNotFoundException cnfe) {
// swallow as we've hit the max class version that we have
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Mladen Turk wrote: -Original Message- From: Andy Armstrong Heretic perhaps, but I'd like to integrate PHP (perhaps even Perl) directly with TC. What do you mean by 'integrate'? Have tomcat handle PHP requests by some means? mod_php inside TC. I found out that TC is only 8% slower the Apache2.x. So if I need PHP and JSP, the Apache2 is total overhead. MT. I hope this is an April 1 joke :-) Maybe you can also integrate mod_perl and mod_dotnet ( or whatever is called ) :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 15278] - [PATCH] mod_jk2 for IIS, Bugfix corrupted data ]
From: [EMAIL PROTECTED]
Yes i will be willing to help with
the test. I can install the version on the dev server which
is IIS 5.0 with TC 5.0 and W2K and use these same machines to
do the test.
As of the email issue, I am subscribed but i get way too many
emails i can't read them all. the bug report is very good
because I am cc ed and i get the email in my inbox rather
than the TC folder.
Well, but that's not the purpose of the bugzilla.
Anyhow I've cc'ed to you.
There is a binary build at:
http://jakarta.apache.org/~mturk/isapi_redirector2.zip
It includes the latest fixes that IMO should resolve the issue.
Waiting for the test results :)
The best would be that you put following in your config to enable DEBUG and
file logging.
I'm interested in the jk_ws_service_t::read lines.
[logger]
info=Native logger
level=DEBUG
[logger.file:0]
level=DEBUG
file=${serverRoot}/logs/jk2.log
[workerEnv:]
info=Global server options
timing=1
debug=0
logger=logger.file:0
...
[uri:/manager/*]
info=Manager Application.
context=/manager
debug=10
MT.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@lsd]: jakarta-tomcat-5/jakarta-tomcat-5 failed
To whom it may engage... This is an automated request, but not an unsolicited one. For help understanding the request please visit http://gump.apache.org/nagged.html, and/or contact [EMAIL PROTECTED] Project jakarta-tomcat-5 has an issue affecting its community integration, and has been outstanding for 3 runs. The current state is 'Failed', for reason 'Build Failed' Full details are available at: http://lsd.student.utwente.nl/gump/jakarta-tomcat-5/jakarta-tomcat-5.html, however some snippets follow: - - - - - -- -- G U M P Gump provided these annotations: - Info - Jar [servlets-default.jar] identifier set to jar basename: [servlets-default] - Info - Jar [naming-common.jar] identifier set to jar basename: [naming-common] - Info - Jar [naming-resources.jar] identifier set to jar basename: [naming-resources] - Info - Jar [catalina.jar] identifier set to jar basename: [catalina] - Info - Jar [bootstrap.jar] identifier set to jar basename: [bootstrap] - Info - Jar [servlets-common.jar] identifier set to jar basename: [servlets-common] - Info - Jar [servlets-invoker.jar] identifier set to jar basename: [servlets-invoker] - Info - Dependency on javamail exists, no need to add for property mail.jar. - Info - Dependency on jaf exists, no need to add for property activation.jar. - Info - Dependency on jakarta-servletapi-5-servlet exists, no need to add for property servlet-api.jar. - Info - Dependency on jakarta-servletapi-5-jsp exists, no need to add for property jsp-api.jar. - Info - Dependency on xml-xerces exists, no need to add for property xercesImpl.jar. - Info - Dependency on xml-xerces exists, no need to add for property xmlParserAPIs.jar. - Info - Dependency on jakarta-tomcat-util exists, no need to add for property tomcat-util.jar. - Info - Dependency on commons-el exists, no need to add for property commons-el.jar. - Info - Dependency on commons-logging exists, no need to add for property commons-logging-api.jar. - Info - Dependency on commons-modeler exists, no need to add for property commons-modeler.jar. - Info - Dependency on ant exists, no need to add for property ant.home. - Info - Dependency on jsse exists, no need to add for property jsse.home. - Info - Dependency on jmx exists, no need to add for property jmx.home. - Info - Dependency on jmx exists, no need to add for property jmx.jar. - Info - Dependency on jmx exists, no need to add for property jmx-tools.jar. - Info - Dependency on jndi exists, no need to add for property jndi.home. - Info - Dependency on jakarta-regexp exists, no need to add for property regexp.home. - Info - Dependency on jakarta-regexp exists, no need to add for property regexp.jar. - Info - Dependency on javamail exists, no need to add for property mail.home. - Info - Dependency on jakarta-tomcat-coyote exists, no need to add for property tomcat-coyote.home. - Info - Dependency on jakarta-tomcat-jasper_tc5 exists, no need to add for property jasper.home. - Info - Dependency on jaf exists, no need to add for property activation.home. - Info - Dependency on commons-modeler exists, no need to add for property commons-modeler.home. - Info - Dependency on commons-daemon exists, no need to add for property commons-daemon.jsvc.tar.gz. - Info - Dependency on jakarta-struts exists, no need to add for property struts.home. - Info - Enable verbose output, due to 2 previous error(s). - Info - Failed with reason build failed - Info - Enable debug output, due to build failure. - - - - - -- -- G U M P Gump performed this work: http://lsd.student.utwente.nl/gump/jakarta-tomcat-5/gump_work/build_jakarta-tomcat-5_jakarta-tomcat-5.html Work Name: build_jakarta-tomcat-5_jakarta-tomcat-5 (Type: Build) State: Failed Elapsed: 0 hours, 1 minutes, 16 seconds Command Line: java -Xbootclasspath/p:/data3/gump/xml-xerces2/java/build/xercesImpl.jar:/data3/gump/xml-xerces2/java/build/xml-apis.jar:/data3/gump/xml-xalan/java/build/xalan-unbundled.jar:/data3/gump/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -verbose -Dgump.merge=/data3/gump/gump-install/work/merge.xml -Dbuild.sysclasspath=only -Dtomcat33.home=*Unset* -Djsp-api.jar=/data3/gump/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar -Dtomcat-coyote.home=/data3/gump/jakarta-tomcat-connectors/coyote -Djndi.jar=/data3/gump/opt/jndi1_2_1/lib/jndi.jar -Dsite2.home=/data3/gump/jakarta-site2 -DxmlParserAPIs.jar=/data3/gump/xml-xerces2/java/build/xercesImpl.jar -Dactivation.home=/data3/gump/opt/jaf-1.0.1 -Djmx.home=/data3/gump/opt/jmx-1_2-ri -Djdbc20ext.jar=/data3/gump/opt/jdbc2_0/jdbc2_0-stdext.jar -Djmx-tools.jar=/data3/gump/opt/jmx-1_2-ri/lib/jmxtools.jar -Dregexp.jar=/data3/gump/jakarta-regexp/build/jakarta-regexp-20040403.jar -Dmail.home=/data3/gump/opt/javamail-1.3 -Dant.home=/data3/gump/ant/dist -Dcommons-modeler.home=/data3/gump/jakarta-commons/modeler
RE: TC evolment
From Costin Manolache mod_php inside TC. I found out that TC is only 8% slower the Apache2.x. So if I need PHP and JSP, the Apache2 is total overhead. MT. I hope this is an April 1 joke :-) Maybe you can also integrate mod_perl and mod_dotnet ( or whatever is called ) :-) Someone told me back in '80 that he's going to install the 1MB of RAM to some mainframe. I thought it was a April 1 joke then, cause I couldn't figure out why would someone need that :-). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Mladen Turk wrote: -Original Message- From: jean-frederic clere What do you want to do? - Call native methods in TC to get PHP running. - Write a servlet engine that understands PHP. (Well the problem would be the libraries). If a majority of my web content is a dynamic one, delivered through JSP, PHP, or what ever, why would I need a dummy web server as an intermediate? That's my thoughts. True, I'm thinking of having native connection to PHP, but that's irrelevant compared to the concept itself. Nowadays we are having connectors (to the so called mighty webservers) to the TC, but I'd like to rotate that a bit. Static content is becoming less and less significant than before, and I cannot imagine a ISP provider that doesn't offer some dynamic content 'connector'. I think that we need to change the thinking perspective from TC being a 'helper' to TC being a 'workhorse'. The webserver is not only for static content. If you use Apache just because it serves the static content faster than tomcat - you are using it for the wrong reason. A lot of people use Apache because they feel it's more stable and secure. Other use it because of the hundreds of modules - like mod_php, mod_perl, etc. Yes, you could make mod_php work with tomcat - or you could even rewrite the entire php in java. And nobody can stop you from doing this if you have the time and itch. But if you just want to use PHP instead of JSP - you may be better just doing it with the existing stable solution, which is Apache. The raw page speed is not everything. There is also the memory use, CPU load, startup time, stability, etc. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion - /jkstatus and stylesheets
Thorsten Kamann wrote: Hello, Henri Gomez schrieb: Well I didn't like very well the hardcoded way, so I'd like to have it externally. We could : Define a stylesheet property var in workers2.properties, which will contains a full URL and if this var is null, fallback to previous method. Is there a chance the jk provides the status as xml? So the status can checked programmatically. With an nice XSL-Stylesheet I can integrate the status in every monitor page . Your comments? I think the status page should be in XML, and more specifically in XHTML. We can have all the class and id attributes that you need to define either a CSS or XSL stylesheet for programatic access. However I don't think inventing another XML format and then adding all the complexity of XSL to just view the status page is the best idea. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion - /jkstatus and stylesheets
Henri Gomez wrote: No problem for me to provide the result in XML, since I've got friend aroud which could provide me some nice XSL still sheet. Second advantage, the jkstatus could be used by others apps for example for monitoring purposes. +0 for XML (lack of time to works on this ;(). -0 - if someone wants to extract data and transform the output of /jkstatus - they can do it using XHTML DTD. Inventing yet another DTD and adding yet another layer - just because we can or we like complexity - is IMO a bad choice. So we should now define a DTD. There are already far too many DTDs. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TC evolment
From Costin Manolache Sent: Saturday, April 03, 2004 9:14 AM If a majority of my web content is a dynamic one, delivered through JSP, PHP, or what ever, why would I need a dummy web server as an intermediate? The webserver is not only for static content. If you use Apache just because it serves the static content faster than tomcat - you are using it for the wrong reason. Yes, but I found myself lately to use it just for glueing those techologies together, of course thanks to the large module database, it's not such a big deal. Having every content passing several systems is not so stable solution thought, cause each channel will add it's risk percentage. The raw page speed is not everything. There is also the memory use, CPU load, startup time, stability, etc. And there is the maintainability, scalability, etc. which I think Java is better at. As you said nothing stops me of doing something like that, and of course nothing stops me being totally wrong :). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC evolment
Mladen Turk wrote: From Costin Manolache Sent: Saturday, April 03, 2004 9:14 AM If a majority of my web content is a dynamic one, delivered through JSP, PHP, or what ever, why would I need a dummy web server as an intermediate? The webserver is not only for static content. If you use Apache just because it serves the static content faster than tomcat - you are using it for the wrong reason. Yes, but I found myself lately to use it just for glueing those techologies together, of course thanks to the large module database, it's not such a big deal. Having every content passing several systems is not so stable solution thought, cause each channel will add it's risk percentage. If you're worried about risk, then probably glueing PHP with tomcat will be a bad choice. Tomcat is limited by Java's bad support for integration with native code. Apache will have no problem running Php, perl, python, .net or integrating with any native library that exists today. For tomcat running openSSL seems to be a big thing, and we know too well how difficult it is to get it working with JNI. For tomcat - you can attempt to rewrite/replace every feature in Java ( we are doing this for LDAP auth for example - not sure if JNDI is better or faster than the native ldap auth in apache ). Or you can try to use JNI or connectors - like mod_jk. Or you can just use what already works and is stable, and do something better with your time :-) The raw page speed is not everything. There is also the memory use, CPU load, startup time, stability, etc. And there is the maintainability, scalability, etc. which I think Java is better at. Java may be more maintainable - but in this particular case do you think PHP + JNI/connector + tomcat would be more maintainable than the existing and well tested Apache + mod_php ? About scalability - April 1 is over on my timezone :-) As you said nothing stops me of doing something like that, and of course nothing stops me being totally wrong :). Well, what would be wrong is to not try if you think it's a good idea:-) I'm allways interested in integration between Java and native code - and even if I don't think Tomcat+PHP would stand a chance to Apache+mod_php - I'm looking forward to see more work in the area of JNI or connectivity between java and the rest of the world. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion - /jkstatus and stylesheets
Hello Henri Henri Gomez schrieb: No problem for me to provide the result in XML, since I've got friend aroud which could provide me some nice XSL still sheet. Second advantage, the jkstatus could be used by others apps for example for monitoring purposes. +0 for XML (lack of time to works on this ;(). So we should now define a DTD. Do we need multiple XMLs and DTDs. The jkstatus provides 4 different sites. Should the content of the 4 HTML-Pages merged into one XML? Do we need really a DTD? Is the configurations entry not to complex for a dtd? If you want I can try to create a draft of a jkstatus xml. Best regards Thorsten -- Thorsten Kamann Email: [EMAIL PROTECTED] ICQ: 40746578 Yahoo: ThorQue - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 and debug on specials uri
Good evening Henri, Wouldn't it be Location /examples/* JkUriSet group lb JkUriSet debug 1 Location or JkSet uri:/examples/*.debug 1 or JkSet2 uri:/examples/* debug 1 AFAIK of the docs. :-) Norm - Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, April 02, 2004 4:11 PM Subject: jk2 and debug on specials uri Hi to all, A quick question : I've got the following in a VirtualHost (Apache 2): Location /examples/* JkUriSet group lb Location I'd like to have this /examples/ uri in debug and wonder how to do it. - 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 28129] - Classloading for the security-constraint / Realm
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=28129. 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=28129 Classloading for the security-constraint / Realm --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 10:19 --- Well i tried to upload (attach) a simple test case, but i seems it doesn't work. So here is a link (http://www.gehmtec.de/bugzilla/securitytest.zip) to a zip file (~2 MB) with a securitytest.war and the server.xml. I don't get any ClassNotFound exceptions, that would be easy, i think the problem is that a wrong/old Class is loaded for the security. But i haven't found it yet. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28154] New: - setting of mappedfile in web.xml doesn't work
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=28154. 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=28154 setting of mappedfile in web.xml doesn't work Summary: setting of mappedfile in web.xml doesn't work Product: Tomcat 5 Version: 5.0.14 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] as an aside, in some apache docs, it refers to mappedFile, so I also tried that. setting mappedfile to true doesn't cause multiple lines of html in the source to combined into a single write statement. I have checked that largefiles is off, development is off, and turned off debugging in server.xml here's fragment of my web.xml: servlet servlet-namejsp/servlet-name servlet-classorg.apache.jasper.servlet.JspServlet/servlet-class init-param param-namefork/param-name param-valuetrue/param-value /init-param init-param param-namexpoweredBy/param-name param-valuefalse/param-value /init-param !-- mappedfile Should we generate static content with one -- !-- print statement per input line, to ease-- !-- debugging? [true]-- !-- PADM: some tomcat docs refer to mixed case name -- init-param param-namemappedfile/param-name param-valuefalse/param-value /init-param init-param param-namemappedFile/param-name param-valuefalse/param-value /init-param !-- classdebuginfo Should the class file be compiled with-- !-- debugging information? [true]-- init-param param-nameclassdebuginfo/param-name param-valuefalse/param-value /init-param !-- developmentIs Jasper used in development mode (will check -- !-- for JSP modification on every access)? [true] -- init-param param-namedevelopment/param-name param-valuefalse/param-value /init-param !-- trimSpaces Should white spaces in template text between -- !-- actions or directives be trimmed? [false] -- init-param param-nametrimspaces/param-name param-valuetrue/param-value /init-param load-on-startup3/load-on-startup /servlet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28156] New: - Session Expiration in Cluster broken after stopping one node
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=28156. 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=28156 Session Expiration in Cluster broken after stopping one node Summary: Session Expiration in Cluster broken after stopping one node Product: Tomcat 5 Version: 5.0.21 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina:Cluster AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] After stopping one cluster node, expiration of the sessions replicated from this node to the other nodes is broken. This is due to a bug in DeltaManager.java. In line 882 there is a call to session.access(), which increases accessCount by 1. Since there is no call to session.endAccess, this session will never expire. The same seems to be true in line 870. If it is necessary to update timestamps with session.access, you should also call session.setAccessCount(0) directly after. In line 870 this might be appropriate, in line 882 there is dreq.execute directly before and dreq.execute already calls session.access and session.endAccess, so I think one could drop line 882. The Bug was first introduced in Version 1.8 of DeltaManager (TC 5.0.18). Since there was already another bug relating to accessCount0 it seems to be a good idea to check other uses of accessCount or session.access() as well. Thanks for correcting. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28156] - Session Expiration in Cluster broken after stopping one node
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=28156. 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=28156 Session Expiration in Cluster broken after stopping one node [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 11:16 --- *** This bug has been marked as a duplicate of 28131 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28131] - DeltaManager lost session expiration code line
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=28131. 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=28131 DeltaManager lost session expiration code line --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 11:16 --- *** Bug 28156 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session DeltaSession.java
[EMAIL PROTECTED] wrote: fhanik 2004/04/01 13:06:50 Modified:modules/cluster/src/share/org/apache/catalina/cluster/session DeltaSession.java Log: bugfix for 28131, thanks to rainer.jung -at- kippdata.de So I assume you're going to want a 5.0.22 ? :( This is a consequence of not extending StandardSession. Is this really not possible to do ? In JBoss, it works fine, and it avoids that kind of maintenance issue. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28156] - Session Expiration in Cluster broken after stopping one node
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=28156. 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=28156 Session Expiration in Cluster broken after stopping one node [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 11:19 --- It is not a duplicate of 28131, which was also found by me. 28131 prevented any expiration in a cluster. This bug here only applies if one cluster node is shutdown. Then the replicated sessions will no longer expire. 28131 is resolved in DeltaSession.java, this bug here must be resolved in DeltaManager.java. Please leave open for comment by Filip Hanik. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationContext.java
Mark Thomas wrote: Remy, Looking at bug 13040 I did a bugzilla search and came across bug 11411. I am still thinking about bug 13040 but saw that bug 11411 could be fixed (I had previously closed it without looking at the source closely enough) without getting into the equals()/startsWith() debate that is part of bug 13040. In the circumstances where crossContext is false and getContext(/) is called from within the root web application getContext() was returning null rather than the root context. I am guessing I have done something stupid but I cant for the life of me see what it is ;) I suppose your patch merely allows for a shortcut, so it could be acceptable. Rmy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28157] New: - mod_jk fails to pass GET parameters to servlets
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=28157. 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=28157 mod_jk fails to pass GET parameters to servlets Summary: mod_jk fails to pass GET parameters to servlets Product: Tomcat 5 Version: 5.0.0 Platform: Sun OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Native:JK AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] mod_jk both 1 2 on apache1.3x using both tomcat 4 5 fail to send arguments after the question mark to servlets. JSP pages are fine, but servlets request only work with post. Both binary distribution and self compiled versions of mod jk used. property file is as follows # Define 1 real worker using ajp13 worker.list=worker1 # Set properties for worker1 (ajp13) worker.worker1.type=ajp13 worker.worker1.host=127.0.0.1 worker.worker1.port=8009 worker.worker1.lbfactor=50 worker.worker1.cachesize=10 worker.worker1.cache_timeout=600 worker.worker1.socket_keepalive=1 worker.worker1.socket_timeout=300 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK2 Connector and denial of service attacks
At 10:36 PM 29/03/2004, you wrote: Henri Gomez wrote: Steve Spicer wrote: On standard install it doesn't. I'm not sure why but it still seems the JK connector is connecting to tomcat even though the access checker hook is returning a 403. Any ideas? I will make some tests on it. I make some tests and I didn't see such problems. The first request to http://mymachine/examples/ were forwarded to tomcat, but the rest was forbideen (403) by mod_dosevasive. I used test.pl provided in mod_dosevasise. Same thing with ab (ApacheBench). So what's your problem ? Although I get 403 status it still seems to be spawning lots of HTTPD's and tomcat takes cpu time, surely if the 403 worked the extra HTTPD would not spwan and tomcat would be unaffected? Im beginning to think I have some config issues, I'll check them all out and get back if theres still an issue. - 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 28158] New: - Context reloadable=true not working if autodeploy=false
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=28158. 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=28158 Context reloadable=true not working if autodeploy=false Summary: Context reloadable=true not working if autodeploy=false Product: Tomcat 5 Version: 5.0.18 Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] A context will not be reloaded automatically if autodeploy has been activated. This is a problem, because if I *do* activate autodeploy, a wepapp gets deployed twice. Once according to server.xml and once automatically. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28158] - Context reloadable=true not working if autodeploy=false
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=28158. 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=28158 Context reloadable=true not working if autodeploy=false [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 13:28 --- This is normal behavior. Webapps will be deployed if they are in appBase. Use context files rather than context declarations in server.xml. reloadable is also independant of the auto deployer, but wil only reload if classes are modified. Post on tomcat-user for this kind of issues, and don't reopen this report. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28157] - mod_jk fails to pass GET parameters to servlets
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=28157. 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=28157 mod_jk fails to pass GET parameters to servlets [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 13:29 --- Please post about this issue on tomcat-user. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28158] - Context reloadable=true not working if autodeploy=false
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=28158. 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=28158 Context reloadable=true not working if autodeploy=false --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 13:35 --- reloadable is also independant of the auto deployer, but wil only reload if classes are modified. If you say that reloadable is independant of the autodeploayer, then reloadable with autodeploy=false should work and this bug would be valid. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28158] - Context reloadable=true not working if autodeploy=false
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=28158.
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=28158
Context reloadable=true not working if autodeploy=false
--- Additional Comments From [EMAIL PROTECTED] 2004-04-02 13:41 ---
If you look at the code, you'll see that class reloading is indeed independant
of auto deploy. This should be obvious enough (see below for the code in the
context). See, I'm sort of tired wasting my time testing non issues, so if you
could be convincing it would help me think this is going to be quality time.
/**
* Execute a periodic task, such as reloading, etc. This method will be
* invoked inside the classloading context of this container. Unexpected
* throwables will be caught and logged.
*/
public void backgroundProcess() {
if (!started)
return;
count = (count + 1) % managerChecksFrequency;
if ((getManager() != null) (count == 0)) {
try {
getManager().backgroundProcess();
} catch ( Exception x ) {
log.warn(Unable to perform background process on manager,x);
}
}
if (getLoader() != null) {
if (reloadable (getLoader().modified())) {
try {
Thread.currentThread().setContextClassLoader
(StandardContext.class.getClassLoader());
reload();
} finally {
if (getLoader() != null) {
Thread.currentThread().setContextClassLoader
(getLoader().getClassLoader());
}
}
}
if (getLoader() instanceof WebappLoader) {
((WebappLoader) getLoader()).closeJARs(false);
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28158] - Context reloadable=true not working if autodeploy=false
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=28158. 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=28158 Context reloadable=true not working if autodeploy=false --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 13:55 --- I don't intend to waste your time. Reporting a bug costs my time too, so I only do it if I think I found a bug, not to missuse bugzilla as a forum. I don't know if the code you provided is correct or not, as I don't have insight in the tomcat source. I just managed to reproduce the following behaviour in Tomcat 5 (and 4), which is faulty IMO: Auto-reload works fine as long as I have autodeploy=true for the host my context resits in. As soon is I trun autodeploy off, reloading of the context doesn't work anymore. So the relaoding-feature of a webapp seems to be somehow dependant of the autodeploy feature on the host. I posted the second part with the multiple deployment only to show why I think fixing this is important. I'm glad to post a server.xml to show what I think is a bug. Maybe you could confirm it then. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
compiling mod_jk 2.0.4 on macos X (10.2)
i'm trying to compile mod_jk (just the apache side, not the tomcat side). I downloaded jakarta-tomcat-connectors-jk2-2.0.4-src. apr-0.9.4 and apr-util-0.9.4 and was able to successfully run configure (i'm building against apache 1.3). however trying to do make results in an error about build/jk2/apache13/mod_jk2.so not existing (it doesn't). i have all the .o files and i have mod_jk2.a and mod_jk2.la, why isn't the .so file being built? Attempts to build against apache2 result in configure errors about libapr not being found. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28158] - Context reloadable=true not working if autodeploy=false
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=28158. 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=28158 Context reloadable=true not working if autodeploy=false --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 14:21 --- Ok, so: - I tested and it works - (as I said but you don't want to listen) don't use server.xml, use a context file with a name matching the context name - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28158] - Context reloadable=true not working if autodeploy=false
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=28158. 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=28158 Context reloadable=true not working if autodeploy=false --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 14:29 --- - I tested and it works How can you know if it works if you don't have my server.xml? - (as I said but you don't want to listen) don't use server.xml, use a context file with a name matching the context name I did listen. Its just not a solution. Its as valid to put the whole configuration in the server.xml as it is to put it into individual files. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28159] New: - Servlet destroy methods are called in the wrong order
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=28159. 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=28159 Servlet destroy methods are called in the wrong order Summary: Servlet destroy methods are called in the wrong order Product: Tomcat 5 Version: 5.0.19 Platform: All OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If I specify a load order for three servlets in web.xml servlet servlet-nameone/servlet-name servlet-classClassOne/servlet-class load-on-startup1/load-on-startup /servlet servlet servlet-nametwo/servlet-name servlet-classClassTwo/servlet-class load-on-startup2/load-on-startup /servlet servlet servlet-namethree/servlet-name servlet-classClassThree/servlet-class load-on-startup3/load-on-startup /servlet Then they are initialised one, two, three as expected. However when tomcat is shutdown their destroy methods are called one, two, three rather than three, two, one. This must be wrong as servlet one could create (and destroy) resources on which the operation of servlet two (including its destroy method) are dependent. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28158] - Context reloadable=true not working if autodeploy=false
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=28158. 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=28158 Context reloadable=true not working if autodeploy=false --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 14:34 --- Created an attachment (id=11103) server.xml used (see comment in file) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session DeltaManager.java
fhanik 2004/04/02 06:42:20
Modified:modules/cluster/src/share/org/apache/catalina/cluster/session
DeltaManager.java
Log:
Fixed bug 28156. Session access count should be 0 not 1 when the requests are done
Revision ChangesPath
1.19 +2 -2
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
Index: DeltaManager.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- DeltaManager.java 1 Mar 2004 21:35:34 - 1.18
+++ DeltaManager.java 2 Apr 2004 14:42:20 - 1.19
@@ -869,6 +869,7 @@
if (session != null) {
session.access();
session.setPrimarySession(false);
+ session.endAccess();
}
break;
}
@@ -879,7 +880,6 @@
DeltaRequest dreq = loadDeltaRequest(session, delta);
dreq.execute(session);
session.setPrimarySession(false);
- session.access();
}
break;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: compiling mod_jk 2.0.4 on macos X (10.2)
Hi Marco, It sounds like the configure script is telling Make (*simplification*) to only build static files (.la), which is bizarre. Try running configure with the following option to force it to build the shared (.so) libraries: ./configure --enable-shared=yes ... *plus other options as usual* Then do: make clean make as usual. Hope that helps, Adam. -Original Message- From: Marco Baringer [mailto:[EMAIL PROTECTED] Sent: 02 April 2004 15:03 To: [EMAIL PROTECTED] Subject: compiling mod_jk 2.0.4 on macos X (10.2) i'm trying to compile mod_jk (just the apache side, not the tomcat side). I downloaded jakarta-tomcat-connectors-jk2-2.0.4-src. apr-0.9.4 and apr-util-0.9.4 and was able to successfully run configure (i'm building against apache 1.3). however trying to do make results in an error about build/jk2/apache13/mod_jk2.so not existing (it doesn't). i have all the .o files and i have mod_jk2.a and mod_jk2.la, why isn't the .so file being built? Attempts to build against apache2 result in configure errors about libapr not being found. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ This email and any files attached is intended for the addressee only and may contain information that is confidential and/or legally privileged. Unauthorised use is strictly prohibited and may be unlawful. If you are not the addressee, you should not read, copy, disclose or otherwise use this message, including any attachment, except for the purpose of delivery to the addressee. We make every effort to keep our network free from viruses. However, you do need to verify this e-mail and any attachments to it to be virus free as we can take no responsibility for any computer virus which might be transferred by way of this e-mail. Scanning of this message and addition of this footer is performed by SurfControl E-mail Filter software in conjunction with virus detection software. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28156] - Session Expiration in Cluster broken after stopping one node
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=28156. 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=28156 Session Expiration in Cluster broken after stopping one node [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 14:43 --- Thanks for the info, I haven't had time to play around with all this since we just moved from California to Texas. Thanks for your help!! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling mod_jk 2.0.4 on macos X (10.2)
From: Marco Baringer [EMAIL PROTECTED] i'm trying to compile mod_jk (just the apache side, not the tomcat side). I downloaded jakarta-tomcat-connectors-jk2-2.0.4-src. apr-0.9.4 and apr-util-0.9.4 and was able to successfully run configure (i'm building against apache 1.3). however trying to do make results in an error about build/jk2/apache13/mod_jk2.so not existing (it doesn't). i have all the .o files and i have mod_jk2.a and mod_jk2.la, why isn't the .so file being built? Is there a jk/build/jk2/apache13/usr/local/libexec/mod_jk2.dylib? You could try editing jk/native2/server/apache13/Makefile and change all .so to .dylib and see if that helps. Attempts to build against apache2 result in configure errors about libapr not being found. This has been reported and fixed post 2.0.4. A quick workaound would be to edit jk/native2/configure, find all the referances to libapr-1.so, libapr-0.so and libapr.so and change to libapr-1.dylib, libapr-0.dylib and libapr.dylib respectively. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen - 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 and debug on specials uri
NormW wrote: Good evening Henri, Wouldn't it be Location /examples/* JkUriSet group lb JkUriSet debug 1 Location I tried but it didn't works ;( or JkSet uri:/examples/*.debug 1 or JkSet2 uri:/examples/* debug 1 Well it didn't works neither. I'm using these 2 on a VirtualHost - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling mod_jk 2.0.4 on macos X (10.2)
Kurt Miller wrote: From: Marco Baringer [EMAIL PROTECTED] i'm trying to compile mod_jk (just the apache side, not the tomcat side). I downloaded jakarta-tomcat-connectors-jk2-2.0.4-src. apr-0.9.4 and apr-util-0.9.4 and was able to successfully run configure (i'm building against apache 1.3). however trying to do make results in an error about build/jk2/apache13/mod_jk2.so not existing (it doesn't). i have all the .o files and i have mod_jk2.a and mod_jk2.la, why isn't the .so file being built? Is there a jk/build/jk2/apache13/usr/local/libexec/mod_jk2.dylib? You could try editing jk/native2/server/apache13/Makefile and change all .so to .dylib and see if that helps. Attempts to build against apache2 result in configure errors about libapr not being found. This has been reported and fixed post 2.0.4. A quick workaound would be to edit jk/native2/configure, find all the referances to libapr-1.so, libapr-0.so and libapr.so and change to libapr-1.dylib, libapr-0.dylib and libapr.dylib respectively. There is a fix in jk2 CVS to fix this .dylib - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 and debug on specials uri
Henri Gomez wrote: NormW wrote: Good evening Henri, Wouldn't it be Location /examples/* JkUriSet group lb JkUriSet debug 1 Location I tried but it didn't works ;( or JkSet uri:/examples/*.debug 1 or JkSet2 uri:/examples/* debug 1 Well it didn't works neither. I'm using these 2 on a VirtualHost I'm looking to fix a problem with charset encoding and it seems that in jk2_service_apache2_head(), s-uriEnv-mbean-debug is 0 ;( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28159] - Servlet destroy methods are called in the wrong order
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=28159. 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=28159 Servlet destroy methods are called in the wrong order [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 15:22 --- I'm afraid it's not wrong, for the simple reason that according to the spec, the Servlet container is free to destroy a servlet at any time for any reason. Please follow up on [EMAIL PROTECTED] if you require more assistance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28129] - Classloading for the security-constraint / Realm
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=28129. 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=28129 Classloading for the security-constraint / Realm [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 15:38 --- I've just deployed your apps and it works fine for me using j2se 1.4.2_02. Your war also deploy fine in SJS AS 8 PE, and it works fine :-). INFO: Installing web application at context path /securitytest from URL file:/src/jakarta-tomcat-5/build/webapps/securitytest Apr 2, 2004 10:36:28 AM org.apache.commons.beanutils.MethodUtils getMatchingAccessibleMethod WARNING: Cannot use JVM pre-1.4 access bug workaround die to restrictive security manager. BTW, you should not bundle the Xerces jar file under /lib. Those will be ignored by the Tomcat classloader. Maybe that's because you are using an IBM product ;-) Try to use another VM to see if it fixes the problem. But this is clearly not a Tomcat bug. -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Olá! Você pediu para assinar gratuitamente o Relatório. Parabéns!
*** Atenção: se você usa um autorespondente em seu e-mail, pode ser que receba esta mensagem mais de uma vez. Isso acontece porque quando seu autorespondente envia uma mensagem para este endereço, nosso robô despacha automaticamente este e-mail novamente. *** Olá! Obrigado por seu interesse em assinar o Relatório Alfa. Estamos enviando para você uma assinatura GRATUITA do jornal eletrônico Relatório Alfa para que você receba, semanalmente, notícias que não costumam aparecer em outras publicações. Enviamos somente 1 ou 2 edições por semana. *** Você vai receber (se ainda não recebeu) um e-mail de confirmação emitido pela empresa Grupos.Com.Br com o título \CONFIRME SUA ASSINATURA, perguntando se você deseja receber o Relatório. Devolva o e-mail (usando o mesmo endereço que você usou para pedir sua assinatura) e passaremos a enviar o jornal eletrônico semanalmente para você. NÃO SE TRATA DE UM GRUPO DE DISCUSSÃO POR INTERNET! *** Apesar da empresa que controla nossos assinantes chamar-se GRUPOS.COM.BR, o Relatório Alfa é somente um jornal eletrônico, com mais de 114 mil assinantes em 74 países fundado há quase seis anos e com muita credibilidade. Não divulgamos seu endereço para ninguém. Para conhecer melhor o Relatório Alfa, visite nosso portal aqui: http://www.relatorioalfa.com.br BÔNUS ESPECIAL -- ACADEMIA NOVAK Além de enviarmos uma assinatura gratuita do Relatório Alfa, você também receberá uma outra assinatura TAMBÉM GRATUITA, do boletim \COM O PÉ DIREITO\, publicação SEMANAL, enviada toda segunda-feira, também escrita pelo jornalista Aldo Novak. Este boletim não é jornalístico, mas sim motivacional e estratégico. Novak é um dos mais conhecidos conferencistas do Brasil. Ele dá treinamento de superação pessoal, desenvolvimento, organização de carreira, gestão do tempo... e muito mais. Este boletim é assinado por mais de 110 MIL pessoas em 70 nações diferentes. Como você pode notar, está ajudando muita gente a ter mais sucesso. A empresa de Aldo, a ACADEMIA NOVAK, ensinará você a ter uma vida mais poderosa, mais rica, mais feliz e mais organizada. *** Da mesma forma que acontece com o Relatório Alfa, você receberá um e-mail do Grupos.Com.Br pedindo sua confirmação para receber os boletins da Academia Novak. Devolva o e-mail (usando o mesmo endereço que você usou para pedir a assinatura do Relatório) e passaremos a enviar este boletim eletrônico semanalmente para você. *** O site da Academia Novak está em construção, mas você pode visitar nosso fórum visitando este link: http://www.academianovak.com.br/forum Um grande abraço, Equipe Relatório Alfa e Academia Novak RELATÓRIO ALFA - Descubra o que não querem que você saiba http://www.relatorioalfa.com.br Para ver os 20 artigos mais lidos do Relatório Alfa, este ano, clique aqui: http://www.relatorioalfa.com.br/modules.php?name=Top Para participar livremente em nosso fórum de debates clique abaixo: http://www.relatorioalfa.com.br/modules.php?name=Forums Para pesquisar nossos arquivos de matérias, clique em: http://www.relatorioalfa.com.br/modules.php?name=Stories_Archive Tudo isso e muito mais em http://www.relatorioalfa.com.br BREVE: ALFABLOG -- os usuários registrados poderão publicar seus próprios jornais eletrônicos, dentro do Relatório Alfa. ACADEMIA NOVAK DO BRASIL - Porque Acertar é Humano http://www.academianovak.com.br http://www.academianovak.com.br/forum - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28161] New: - Replication messages get lost with AsyncSocketSender
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=28161. 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=28161 Replication messages get lost with AsyncSocketSender Summary: Replication messages get lost with AsyncSocketSender Product: Tomcat 5 Version: 5.0.21 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Catalina:Cluster AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Using AsyncSocketSender we see, that under heavy load some session get not replicated. We added a lot of debug output statements, so we can see, that in AsyncSocketSender Method sendMessage(data) is reached and we finally end at the line, where the data is written to the socket. Unfortunately on the remote side we miss the incoming messages corresponding to the missing session, although most sessions are replicated and we can see accordingly debugging output. We use a 2 node Cluster using apache/mod_jk with load balancing/routing to both cluster nodes. We create app. 1500 sessions in a few seconds. Nearly 5% of the sessions are missing. Some of the sessions of node 1 are missing on node 2, but also some of the sessions from node 2 are missing on node 1. We couldn't observe the problems under low load. Cluster-Config: useDirtyFlag=true, mcastFrequency=500, mcastDropTime=3000, tcpSelectorTimeout=1000, tcpThreadCount=2, TC 5.0.21, OS is Solaris 9, JVM is 1.4.2_03. Any help is highly appreciated, we are able to produce debugging output. Please give hints. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28158] - Context reloadable=true not working if autodeploy=false
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=28158. 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=28158 Context reloadable=true not working if autodeploy=false --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 15:48 --- Please try to read my comments. Thanks. don't use server.xml, use a context file with a name matching the context name - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Olá! Você pediu para assinar gratuitamente o Relatório. Parabéns!
*** Atenção: se você usa um autorespondente em seu e-mail, pode ser que receba esta mensagem mais de uma vez. Isso acontece porque quando seu autorespondente envia uma mensagem para este endereço, nosso robô despacha automaticamente este e-mail novamente. *** Olá! Obrigado por seu interesse em assinar o Relatório Alfa. Estamos enviando para você uma assinatura GRATUITA do jornal eletrônico Relatório Alfa para que você receba, semanalmente, notícias que não costumam aparecer em outras publicações. Enviamos somente 1 ou 2 edições por semana. *** Você vai receber (se ainda não recebeu) um e-mail de confirmação emitido pela empresa Grupos.Com.Br com o título \CONFIRME SUA ASSINATURA, perguntando se você deseja receber o Relatório. Devolva o e-mail (usando o mesmo endereço que você usou para pedir sua assinatura) e passaremos a enviar o jornal eletrônico semanalmente para você. NÃO SE TRATA DE UM GRUPO DE DISCUSSÃO POR INTERNET! *** Apesar da empresa que controla nossos assinantes chamar-se GRUPOS.COM.BR, o Relatório Alfa é somente um jornal eletrônico, com mais de 114 mil assinantes em 74 países fundado há quase seis anos e com muita credibilidade. Não divulgamos seu endereço para ninguém. Para conhecer melhor o Relatório Alfa, visite nosso portal aqui: http://www.relatorioalfa.com.br BÔNUS ESPECIAL -- ACADEMIA NOVAK Além de enviarmos uma assinatura gratuita do Relatório Alfa, você também receberá uma outra assinatura TAMBÉM GRATUITA, do boletim \COM O PÉ DIREITO\, publicação SEMANAL, enviada toda segunda-feira, também escrita pelo jornalista Aldo Novak. Este boletim não é jornalístico, mas sim motivacional e estratégico. Novak é um dos mais conhecidos conferencistas do Brasil. Ele dá treinamento de superação pessoal, desenvolvimento, organização de carreira, gestão do tempo... e muito mais. Este boletim é assinado por mais de 110 MIL pessoas em 70 nações diferentes. Como você pode notar, está ajudando muita gente a ter mais sucesso. A empresa de Aldo, a ACADEMIA NOVAK, ensinará você a ter uma vida mais poderosa, mais rica, mais feliz e mais organizada. *** Da mesma forma que acontece com o Relatório Alfa, você receberá um e-mail do Grupos.Com.Br pedindo sua confirmação para receber os boletins da Academia Novak. Devolva o e-mail (usando o mesmo endereço que você usou para pedir a assinatura do Relatório) e passaremos a enviar este boletim eletrônico semanalmente para você. *** O site da Academia Novak está em construção, mas você pode visitar nosso fórum visitando este link: http://www.academianovak.com.br/forum Um grande abraço, Equipe Relatório Alfa e Academia Novak RELATÓRIO ALFA - Descubra o que não querem que você saiba http://www.relatorioalfa.com.br Para ver os 20 artigos mais lidos do Relatório Alfa, este ano, clique aqui: http://www.relatorioalfa.com.br/modules.php?name=Top Para participar livremente em nosso fórum de debates clique abaixo: http://www.relatorioalfa.com.br/modules.php?name=Forums Para pesquisar nossos arquivos de matérias, clique em: http://www.relatorioalfa.com.br/modules.php?name=Stories_Archive Tudo isso e muito mais em http://www.relatorioalfa.com.br BREVE: ALFABLOG -- os usuários registrados poderão publicar seus próprios jornais eletrônicos, dentro do Relatório Alfa. ACADEMIA NOVAK DO BRASIL - Porque Acertar é Humano http://www.academianovak.com.br http://www.academianovak.com.br/forum - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28147] - JasperException for jsp files that are symbolic links
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=28147. 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=28147 JasperException for jsp files that are symbolic links [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 15:50 --- I do not understand the issue. If linking to resources outside of the webapp root, use allowLinking. If it still does not work, I think this is not going to be fixed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28161] - Replication messages get lost with AsyncSocketSender
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=28161. 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=28161 Replication messages get lost with AsyncSocketSender [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 15:57 --- Async data send means that there is not time guarantee for when the session is delivered. The session should not get lost without any error trace in the logs. I am still debating whether to remove this feature all together, but I left it in for people to play with. I have not found a case where async is useful, but I am sure there is which is why it is still there. Most of the time people want to be ensured that the session gets replicated, that is when pooled mode comes in. also, from experience, using mod_jk in high load can result in lost sessions, cause it sometimes messes up the request and looses the session id. from my experience, pen (siag.nu/pen) works better as a load balancer I strongly suggest to retry the same test with replicationMode=pooled and see if you get better results. Pooled means that replication is synchronous, but on concurrent channels. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28161] - Replication messages get lost with AsyncSocketSender
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=28161. 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=28161 Replication messages get lost with AsyncSocketSender --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 16:45 --- I respect your sugestion to not use asynchronous, although it looked to me like the right way to do it. Just for your information: The messages really get lost, even after we stop load the missing messages don't get replicated. So it's not just a problem of messages getting replicated too late. There are definitely only debug log stetments all the time, except for a few info messages giving mean values for replication data size. No other non debug log statements on any cluster node. Also from what I see I'm pretty sure, that the replication data is written to the Socket. Concerning mod_jk: For this test case we used each session only once. So the correctness of the response through mod_jk somehow didn't matter. We could easily reproduce the same situation using build in Tomcat HTTP Connector (although we didn't do so until now). We will retry using pooled, although I don't like the idea of having up to 25 connections (code constant) and threads for each pair of nodes in the cluster. Also I had the impression, that in pooled mode TCP conections are only used a very short time (I think I remember for only 100 messages? This application will be under heavy load in production). Why do I think asynchronous fits better? In any synchronous situation if the replication is not fast enough I immediately get negative consequences for the application from the user point of view, because the request blocks ressources needed for accepting new requests as long as the replication hasn't finished. So if replication is slow for a few seconds I'm in danger of loosing all free Apache-Slots resp. Tomcat worker threads for incoming requests. When I do asynchronous replication I only loose timely replication of the sesion changes. If I route my request to the primary container, then I still profit from the cluster with respect to availability and servicability (I can shutdown one of the containers without users loosing sessions). For these features it doesn't really matter, if all request are replicated within milliseconds all the time. I'm sorry to bother you, but I think it's an important discussion. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling mod_jk 2.0.4 on macos X (10.2)
On Venerdì, apr 2, 2004, at 16:45 Europe/Rome, Kurt Miller wrote: Is there a jk/build/jk2/apache13/usr/local/libexec/mod_jk2.dylib? no. only .a and .la This has been reported and fixed post 2.0.4. A quick workaound would be to edit jk/native2/configure, find all the referances to libapr-1.so, libapr-0.so and libapr.so and change to libapr-1.dylib, libapr-0.dylib and libapr.dylib respectively. i grabbed the latest CVS to see if that helped but libtool started going mad. Everything built fine (upto mod_jk2.o), then when trying libtool --mode=link i get this: *** Warning: This system can not link to static lib archive /Users/mb/apache/jakarta-tomcat-connectors/jk/native2/apr-0.9.4//lib/ libapr-0.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. which may be related the shared vs. dynamic issue mentioned in another email. Then i get this: ../../libtool: test: : integer expression expected repeated may (~ 30) times. The build then tries to do ar cru for every .o file into mod_jk2.a, ranlib complains a few times about files not having symbols, but I don't think that's a problem. Make then repets these exart same steps (with same error messages) again and at the end tries this: chmod 644 /Users/mb/apache/jakarta-tomcat-connectors/jk/native2/server/apache13/ ../../../build/jk2/apache13//Users/mb/apache/httpd13/libexec/mod_jk2.a libtool: install: warning: remember to run `libtool --finish /Users/mb/apache/httpd13/libexec' /bin/cp ../../../build/jk2/apache13//Users/mb/apache/httpd13/libexec/mod_jk2.so ../../../build/jk2/apache13/mod_jk2.so /bin/cp: ../../../build/jk2/apache13//Users/mb/apache/httpd13/libexec/ mod_jk2.so: No such file or directory make[1]: *** [../../../build/jk2/apache13/mod_jk2.so] Error 1 and dies. I have a directory with all the .o files, what command should i try to build mod_jk2.so ? p.s. - i really think this is a libtool issue on my side, i'll see what i can figure out. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28161] - Replication messages get lost with AsyncSocketSender
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=28161. 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=28161 Replication messages get lost with AsyncSocketSender [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 17:01 --- We will retry using pooled, although I don't like the idea of having up to 25 this is not really a big resource issue, since no threads are holding on to these connections, they just grab one from the queue when it is available, then return it. lets reopen this bug re:/ async, once I get all moved in and have my computers set up I can start testing this again Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28161] - Replication messages get lost with AsyncSocketSender
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=28161. 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=28161 Replication messages get lost with AsyncSocketSender --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 17:04 --- also, the problem with Async, is that it is using only one channel, hence during heavy load, you will not get milli seconds throughput, cause it queues all the messages the solution would be to make an async pooled mode, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling mod_jk 2.0.4 on macos X (10.2)
twas libtool after all. I grabbed a clean cvs tree, deleted jk/native2/libtool, copied in my version of gnu libtool (1.5.2) and everything went smoothly. compiled, built mod_jk2.so and apache seems to like it. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs class-loader-howto.xml
markt 2004/04/02 09:42:46 Modified:webapps/tomcat-docs class-loader-howto.xml Log: - Fix remaining incorrect reference to CATALINA_HOME rather than CATALINA_BASE - Reported by Daniel Rall Revision ChangesPath 1.14 +1 -1 jakarta-tomcat-4.0/webapps/tomcat-docs/class-loader-howto.xml Index: class-loader-howto.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/class-loader-howto.xml,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- class-loader-howto.xml2 Feb 2004 21:40:31 - 1.13 +++ class-loader-howto.xml2 Apr 2004 17:42:45 - 1.14 @@ -27,7 +27,7 @@ application archive./li liFor classes and resources that must be shared across all web applications, place unpacked classes and resources under -code$CATALINA_HOME/shared/classes/code, or place JAR files +code$CATALINA_BASE/shared/classes/code, or place JAR files containing those classes and resources under code$CATALINA_BASE/shared/lib/code./li /ul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PATCH][Tomcat 4.1 docs] Class loader HOWTO
I have just fixed this in CVS. Thanks for the report. Mark -Original Message- From: Daniel Rall [mailto:[EMAIL PROTECTED] Sent: Friday, April 02, 2004 12:26 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [PATCH][Tomcat 4.1 docs] Class loader HOWTO The published Tomcat 4.1's class loader documentation http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader- howto.html says that the directory used by the shared class loader is relative to CATALINA_HOME. According to the source code in catalina/src/share/org/apache/catalina/startup/Bootstrap.java' s main() method and BootstrapService.java's init() method, the documentation is incorrect (it should be CATALINA_BASE). Here's the corresponding code snippet: unpacked[0] = new File(getCatalinaBase(), shared + File.separator + classes); packed[0] = new File(getCatalinaBase(), shared + File.separator + lib); sharedLoader = ClassLoaderFactory.createClassLoader(unpacked, packed, commonLoader); In CVS rev 1.13, half of this problem was corrected. This fix has not be published to the web site. revision 1.13 date: 2004/02/02 21:40:31; author: markt; state: Exp; lines: +5 -5 - Fix 13805. Update docs to show that the shared directory is relative to CATALINA_BASE not CATALINA_HOME. - Reported by Michael Eriksson. Here's the other half of the fix: * webapps/tomcat-docs/class-loader-howto.xml Quick Start: In a follow up to CVS rev 1.13, correct the path to the lib directory used by Catalina's shared class loader (CATALINA_BASE rather than CATALINA_HOME). Index: class-loader-howto.xml === RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/tomcat-docs/class-l oader-howto.xml,v retrieving revision 1.13 diff -u -u -r1.13 class-loader-howto.xml --- class-loader-howto.xml 2 Feb 2004 21:40:31 - 1.13 +++ class-loader-howto.xml 1 Apr 2004 23:14:02 - @@ -27,7 +27,7 @@ application archive./li liFor classes and resources that must be shared across all web applications, place unpacked classes and resources under -code$CATALINA_HOME/shared/classes/code, or place JAR files +code$CATALINA_BASE/shared/classes/code, and JAR files containing those classes and resources under code$CATALINA_BASE/shared/lib/code./li /ul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling mod_jk 2.0.4 on macos X (10.2)
From: Marco Baringer [EMAIL PROTECTED] twas libtool after all. I grabbed a clean cvs tree, deleted jk/native2/libtool, copied in my version of gnu libtool (1.5.2) and everything went smoothly. compiled, built mod_jk2.so and apache seems to like it. Great! I'm assuming that you got it working for apache2, right? From your last email it apears that apache13 on macos X might need some changes. Could you try apache13 and let us know how it goes? -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen - 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]
Edward Furlong/IE/TLS/PwC is out of the office.
I will be out of the office starting 02/04/2004 and will not return until 30/04/2004. I will respond to your message when I return. _ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling mod_jk 2.0.4 on macos X (10.2)
On Venerdì, apr 2, 2004, at 19:43 Europe/Rome, Kurt Miller wrote: Great! I'm assuming that you got it working for apache2, right? From your last email it apears that apache13 on macos X might need some changes. Could you try apache13 and let us know how it goes? no, i got it working an apache13. i haven't tried apache2 yet. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationContext.java
OK then. Now for the tricky bit. Bug 13040 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13040) highlights a rather knotty problem. Having mulled this over for the last few days I have come to the conclusion that we should be using equals() rather than startsWith() My reasons for this are: - The spec says match which to my mind says equals() - It removes the need for special handling for root - It fixes bug 13040 However, changing this will break anything that assumes that the matching is performed on a startsWith() basis. This is bad. Have we ever received clarification from the spec team in this area? If not could someone point me towards someone who may be able to offer some advice. As I see it there are three ways to deal with this: - ignore it - not an option I like - leave the code as is, closing bug 13040 as WONTFIX with an explantion as to why - make the change Thoughts anyone? Mark From: Remy Maucherat [mailto:[EMAIL PROTECTED] I suppose your patch merely allows for a shortcut, so it could be acceptable. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling mod_jk 2.0.4 on macos X (10.2)
From: Marco Baringer [EMAIL PROTECTED] On Venerdì, apr 2, 2004, at 19:43 Europe/Rome, Kurt Miller wrote: Great! I'm assuming that you got it working for apache2, right? From your last email it apears that apache13 on macos X might need some changes. Could you try apache13 and let us know how it goes? no, i got it working an apache13. i haven't tried apache2 yet. OK, great. I believe the person who found the dylib problem got it working with apache2. 2.0.5 may be good for macos X. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28147] - JasperException for jsp files that are symbolic links
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=28147. 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=28147 JasperException for jsp files that are symbolic links [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 18:23 --- No, no, no. There resource, chError.jsp is local. Except that when compiling this project, this file is physically located in a different location, and referenced by a symlink. for example: ls -l index.jsp chError.jsp -- ../common_files/chError.jsp For some reasons, Jasper treats a symbolic link file differently then a regular file. I have a good number of applications and all of them contain chError.jsp. I do not want to make copies of this file so I use symbolic link in each application to link chError.jsp to a common location. Jasper seems to have trouble with that. Once again, this is meant to be a local resource, not something outside of the application. I also don't know what you were referring to when you mentioned allowLinking. I am using JspC with Jasper2. I don't see such an option documented. Thanks, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coyote's ServerSocketFactory problem
First I must say you've been extremely helpful, thank you for your prompt responses! I hate to bug you but I had another implementation question. I looked at JSSESocketFactory and how SSL is done in the connector, but it doesnt address one particular issue I'm having. Basically I have JAAS (GSSAPI) authentication done inside the Socket that my SocketFactory makes. Let's call it GssSocket, and it uses GssInputStream GssOutputStream for the authenticated encrypted communication. Inside the GssSocket I establish the identity (principal) of the incoming request, but have no way to set it into the CoyoteRequest so it can get passed to the target Servlets through the HttpServletRequest. Since all the servlet sees is the CoyoteRequestFacade, I cannot get access to either the GssSocket, or the GssStreams - the only places where the principal of the user is known. It looks like I can't avoid extending one of the Coyote classes after all. What would you suggest to override to be able to extract a string from the Socket and set it as an attribute for the servlets to get at? I'm sorry if this is getting too hairy, but any advice would be great. thanks -anton On Thu, 2004-04-01 at 13:32, Bill Barker wrote: - Original Message - From: Anton Ushakov [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, March 31, 2004 10:59 PM Subject: Re: Coyote's ServerSocketFactory problem Alright, thanks Bill. I have nothing against Tomcat5 and indeed the socketFactory=my.factory attribute works. But is there any way to pass custom parameters to the factory from the conf file? With a Factory element it was possible but with a single attribute am I out of luck? All this IntrospectionUtils business is confusing... The way this works is that all of the Connector attributes are passed on to the Protocol. In the case of the Http11Protocol, the attributes are then passed on to the SocketFactory (via calling the setAttribute method of o.a.t.u.net.ServerSocketFactory). So all you have to do is to set your parameters on the Connector, and they will end up passed to your SocketFactory. You can look at JSSESocketFactory to see how Tomcat handles this for the default SSL connector. On Fri, 2004-03-26 at 18:03, Bill Barker wrote: - Original Message - From: Anton Ushakov [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, March 26, 2004 4:24 PM Subject: Re: Coyote's ServerSocketFactory problem Should I make a bug entry for this? I wanted to get someone from the tomcat dev team to see if I was missing something before flagging this as a bug. The Catalina SocketFactory is deprecated for use with Coyote in 5.x, and it would probably should be for 4.x as well except for the fact that it is still required to set SSL attributes. This means that anything involving this SocketFactory will just get marked as WONTFIX. Passing the socketFactory attribute on to the Protocol might be something (except for the fact that it is working in 5.x means it may not get a lot of attention :). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationContext.java
Mark Thomas wrote: OK then. Now for the tricky bit. Bug 13040 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13040) highlights a rather knotty problem. Having mulled this over for the last few days I have come to the conclusion that we should be using equals() rather than startsWith() My reasons for this are: - The spec says match which to my mind says equals() - It removes the need for special handling for root - It fixes bug 13040 However, changing this will break anything that assumes that the matching is performed on a startsWith() basis. This is bad. Have we ever received clarification from the spec team in this area? If not could someone point me towards someone who may be able to offer some advice. As I see it there are three ways to deal with this: - ignore it - not an option I like - leave the code as is, closing bug 13040 as WONTFIX with an explantion as to why - make the change Thoughts anyone? The rest of the algorithm will do the startsWith, right ? This is why I said it was a shortcut: it will handle the simple case where / is the parameter. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationContext.java
From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Friday, April 02, 2004 8:30 PM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina /core ApplicationContext.java Mark Thomas wrote: OK then. Now for the tricky bit. Bug 13040 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13040) highlights a rather knotty problem. Having mulled this over for the last few days I have come to the conclusion that we should be using equals() rather than startsWith() My reasons for this are: - The spec says match which to my mind says equals() - It removes the need for special handling for root - It fixes bug 13040 However, changing this will break anything that assumes that the matching is performed on a startsWith() basis. This is bad. Have we ever received clarification from the spec team in this area? If not could someone point me towards someone who may be able to offer some advice. As I see it there are three ways to deal with this: - ignore it - not an option I like - leave the code as is, closing bug 13040 as WONTFIX with an explantion as to why - make the change Thoughts anyone? The rest of the algorithm will do the startsWith, right ? This is why I said it was a shortcut: it will handle the simple case where / is the parameter. Fixing bug 13040 requires an additional patch that uses equals() for the whole algorithm. Hence the complications. This is what I was discussing above. Rémy - 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 28168] New: - patch to add webdoclet tags to jspc output
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=28168.
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=28168
patch to add webdoclet tags to jspc output
Summary: patch to add webdoclet tags to jspc output
Product: Tomcat 4
Version: Nightly Build
Platform: Other
OS/Version: Other
Status: NEW
Severity: Enhancement
Priority: Other
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Hi! I like to compile jsp pages into servlets before putting them into
production, and I also like to use webdoclet to generate web.xml. This patch
lets me do both. It just adds a class comment with a couple of webdoclet tages
to jspc's output classes.
Index: jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
retrieving revision 1.38
diff -u -u -r1.38 JspParseEventListener.java
--- jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
21 May 2002 01:40:13 - 1.38
+++ jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
2 Apr 2004 20:08:55 -
@@ -257,10 +257,10 @@
}
private void generateHeader() throws JasperException {
-String servletPackageName = ctxt.getServletPackageName();
+String servletPackageName = null == ctxt.getServletPackageName() ? :
ctxt.getServletPackageName();
String servletClassName = ctxt.getServletClassName();
// First the package name:
-if (! .equals(servletPackageName) servletPackageName != null) {
+if (! .equals(servletPackageName)) {
writer.println(package +servletPackageName+;);
writer.println();
}
@@ -273,6 +273,11 @@
generateAll(FileDeclarationPhase.class);
writer.println();
+writer.println(/**);
+writer.println( * @web.servlet name=\ + servletPackageName + . +
servletClassName + \);
+writer.println( * @web.servlet-mapping url-pattern=\ +
ctxt.getJspFile() + \);
+writer.println( */);
+
writer.print(public class +servletClassName+ extends );
writer.print(extendsClass.equals() ? jspServletBase : extendsClass);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationContext.java
Mark Thomas wrote: Fixing bug 13040 requires an additional patch that uses equals() for the whole algorithm. Hence the complications. This is what I was discussing above. The matching rule can't be fully implemented AFAIK. I think the current algorithm is a nice compromise. Please give examples where you think it's not good enough (and is worthwhile to support), but you will likely end up breaking other stuff. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28170] New: - PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1
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=28170. 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=28170 PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1 Summary: PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1 Product: Tomcat 4 Version: 4.1.30 Platform: Sun OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Here is the situation. We have been reading PDF content through a JSP using Tomcat 4.0.3 for a couple of years. No real problems until I upgraded our website to Tomcat 4.1.30. After that users of Windows IE (5.01, 5.5, 6.0) and Acrobat Reader 6.0.1 (but not Reader 6.0) started having trouble displaying the PDF in the browser window. I am including two files in my test case. The PDF (sample.pdf) which works fine when accessed directly and a cut down version of my open pdf jsp (badpdf.jsp) I looked at bugid=24970, but the patch to Response.class is already in 4.1.30. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28170] - PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1
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=28170. 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=28170 PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1 --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 20:44 --- Created an attachment (id=11107) Test Case for Bug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28170] - PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1
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=28170. 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=28170 PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 20:53 --- This is actually normal. JSP is textual data, so a charset will be sent to the client. Acrobat is broken and doesn't like that (and this is the end of the story). You should either: - use a servlet to generate the PDF (this seems a better match) - hack Jasper a little bit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28168] - patch to add webdoclet tags to jspc output
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=28168.
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=28168
patch to add webdoclet tags to jspc output
--- Additional Comments From [EMAIL PROTECTED] 2004-04-02 21:03 ---
Here's a less intrusive version of the patch; no changes, only adds:
Index: jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
retrieving revision 1.38
diff -u -u -r1.38 JspParseEventListener.java
--- jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
21 May 2002 01:40:13 - 1.38
+++ jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
2 Apr 2004 21:01:58 -
@@ -273,6 +273,15 @@
generateAll(FileDeclarationPhase.class);
writer.println();
+writer.println(/**);
+if (! .equals(servletPackageName) servletPackageName != null) {
+writer.println( * @web.servlet name=\ + servletPackageName + .
+ servletClassName + \);
+} else {
+writer.println( * @web.servlet name=\ + servletClassName + \);
+}
+writer.println( * @web.servlet-mapping url-pattern=\ +
ctxt.getJspFile() + \);
+writer.println( */);
+
writer.print(public class +servletClassName+ extends );
writer.print(extendsClass.equals() ? jspServletBase : extendsClass);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28170] - PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1
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=28170. 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=28170 PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1 --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 21:09 --- I read this supposedly fixed bug 24970: charset appended to content-type even if not text/* Do you care to comment on this? This is the problem. Some comment about how you guys fixed the extra characters for images (but not application mimetypes?) I have not generated any text up to that point in my jsp and would have thought that setting the content type would cause your connectors to behave appropriately. If I am not following the standards then please point me to the document that proves it. I thought that Tomcat was a Reference Implementation. Also my test case works with everyone else and I know that MS IE is a bad actor with its 2X or 3X request mimetype snooping, but you guys certainly have had to deal with that for years. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28170] - PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1
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=28170. 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=28170 PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1 --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 21:13 --- Well, it's what I said. Bug 24970 is about the connector always setting the charset every time. OTOH, JSPs, since they are text, always append the charset in the application layer (here, it's the default HTTP encoding). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28170] - PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1
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=28170. 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=28170 PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1 --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 21:16 --- I'll get back yo you if the servlet doesn't work, but I'd hate to have my developers change things if it won't. Regards, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28170] - PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1
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=28170. 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=28170 PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1 --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 21:22 --- Write a trivial servlet to test, without the actual PDF body generation to test it (and use a telnet to see the headers). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28170] - PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1
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=28170. 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=28170 PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1 --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 21:37 --- In other words, there is a bug/gap/feature in the JSP spec itself that one really cannot return anything but text of some variety or another from a JSP page. Essentially prior to filters you had to use a servlet for anything other than text -- including images, PDFs (which really should not be treated as text for various reasons), etc. Even with filters you JSP page must pass something to the filter which is not the end-binary response whereupon the filter produces the binary responses -- which is not always convenient... This is unfortunate (and something I debated with the spec authors -- especially since no filters existed at the time), but essentially the notions of having to either require any non-text page authors to strictly watch out for or auto-discard whitespace produced by JSP source formatting, etc, were both considered untenable. At this point, I have to agree the spec authors to *some* degree, though it would still be nice to just use the familiar JSP page mechanism for binary output as well, e.g. by setting the page to binary prior to the output writer being flushed and then being able to get a hold of the output *stream* instead of writer. Anyway, to make a long story short -- you'll have deal with the spec implications. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 and debug on specials uri
Good morning Henri. I was speaking from theory, as the only JkSet/JkUriSet entries that I've used so far are setting the worker and some logger values, and they work without problem. One thing you might see is that the JkUriSet/JkSet/JkSet2 directives only update the actual object referred to and not the configuration space, so these settings are not seen on the 'OrigConf' jkstatus page. Also, if you are looking at this closely, consider what should happen if there is duplication of a uri in both workers2.properties and Apache .conf files. As mentioned previously, if both files contain settings that result in the same uri-name, then a second uri object should be omitted and a log warning created. Similarly, if a conf entry updates a non-NULL value then a log warning would be good for that also. [uri:/examples/*] group=lb:worker1 - Location /examples/* JkUriSet info some details JkUriSet group lb:worker2 /Location should show as 2 warnings: 1. Because the uri object already exists, 2. Because the 'group' setting was updated. Norm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15278] - [PATCH] mod_jk2 for IIS, Bugfix corrupted data ]
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=15278. 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=15278 [PATCH] mod_jk2 for IIS, Bugfix corrupted data ] [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 23:26 --- Just wanted to add to this bug that it is still there and there is no doubt. The problem is it doesn't happen all the time. I had two different clients using Windows XP and IE 6 latest service packs and patches installed on both. When I try to upload files from my machine which has the same configuration it works for me. I had JK 1 as well as JK2 installed on the server so after I start getting these error messages I went to IIS and revert back to use the old DLL, I know that this steps work because i have tried it before. Then went back to these machines that were always having troubles and guess what it worked. The version that I tested was the same version that was published in this bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28170] - PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1
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=28170. 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=28170 PDF content through JSP fails in Tomocat 4.1.30, Windows IE and Acrobat Reader 6.0.1 --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 23:27 --- Thanks, I did the telnet trick to see everything: GET /badpdf.jsp HTTP/1.0 Returns: HTTP/1.1 200 OK Set-Cookie: JSESSIONID=FACB1957A5D101E32866F2466D16D929; Path=/ Content-disposition: inline; filename=sample.pdf Content-Type: application/pdf;charset=ISO-8859-1 Content-Length: 32111 Date: Fri, 02 Apr 2004 23:08:46 GMT Server: Apache-Coyote/1.1 Connection: close While GET /sample.pdf HTTP/1.0 Returns: HTTP/1.1 200 OK ETag: W/32111-1080931122000 Last-Modified: Fri, 02 Apr 2004 18:38:42 GMT Content-Type: application/pdf Content-Length: 32111 Date: Fri, 02 Apr 2004 23:11:06 GMT Server: Apache-Coyote/1.1 Connection: close So it looks like servlet time. About PDFs as Text - As someone who beta tested Acrobat 1.0 and has followed it ever since although not as closely since 4.0. Done all kinds of things like Java applets launched from a 3.0 plugin, etc. - Since PDF-1.2 (or so) and linearized/zipped content streams PDFs are no longer 7- bit ASCII. So, I can see where a character set choice might confuse any of the applications upstream of the web server! Also, Jess's point about worrying about linefeeds is something I'm always checking - particularly the one(s) which easily can get tacked on after the last % - PDFs (unless linearized) need the end of the file to find everything - all the objects are found from the end. Here we are the little guys and upstream we have Sun, MSFT and Adobe doing what they will. Peace. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15278] - [PATCH] mod_jk2 for IIS, Bugfix corrupted data ]
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=15278. 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=15278 [PATCH] mod_jk2 for IIS, Bugfix corrupted data ] --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 23:31 --- Just wanted to add, that the test on the previous post was done on both IIS 5.0 on a W2K Sp4 and IIS 6.0 on a W2K3 server. The test failed on both cases when using JK2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
