DO NOT REPLY [Bug 13477] - tomcat 4.1.2 installed from rpms fails to start
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13477. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13477 tomcat 4.1.2 installed from rpms fails to start [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 06:39 --- tomcat4 started is a wrapper which change user id to tomcat4 and then launch tomcat4 with user tomcat4.tomcat4. If you use dtomcat4 as root at anytime, the logs and settings files will be owned by root so at a later time they couldn't be updated by a tomcat4 user process. I didn't see this problem on my box, catalina.out is owned tomcat4.tomcat4. You should as root : remove all files in /var/tomcat4/logs/, check the tomcat-users.xml and jk2.properties in /etc/tomcat4, and make them writeable by tomcat4 if it's not the case. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.1.12: Xerces 2.2 problems - Struts 1.0.2 bug.
Jean-Francois Arcand wrote: Hi, with Tomcat 4.1.12, Xerces 2.2 is throwing the following exception: org.xml.sax.SAXParseException: The string -- is not permitted within comments. at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) This is a bug in the org.apache.struts.digester.Digester class. If you uses Struts 1.1 beta 2 jar file, the bug will not happen. Xerces 2.2 generates a lot of Warnings and the Digester version of Struts 1.0.2 logs an exception instead of a warning. This has been corrected in the current Digester (1.3) we are using. You means in the struts implementation of Digester ? So we have to decide which combinaison we want to support with 4.1.x: 4.1.x = Xerces 2.1 + Struts 1.0.2 5.x = Xerces 2.2 + Struts 1.1b2 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10544] - crossContext for servlets not working
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10544. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10544 crossContext for servlets not working --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 06:51 --- I also found this problem in tomcat 4.0.6 and tomcat 4.1.12. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: commons-daemon release ?
Costin Manolache wrote: Remy Maucherat wrote: Henri Gomez wrote: I wonder if a release of commons-daemon is planned. No, because promoting it to commons proper got vetoed. At the moment, it looks like a split between daemon and launcher will happen. For the record - nobody can 'veto' a promotion to commons or a release. It is a majority vote. If it gets 3 +1 and more +1 than -1 - then it'll pass. I'm willing to change my vote to -0 if the API is fixed to not require applications to implement the daemon interfaces ( I don't like the split init any more than I did - and so I don't plan to use it any time soon ). I remain -1 on tomcat having dependecies on daemon, and probably -0 on bundling daemon with tomcat. As I said, for 'chuid' functionality I prefer using a direct call - I have most of it implemented using jk2, I'll finish this well before 5.0 is released. I prefer to have a C wrapper that start the JVM and call methods than having the reverse. I have rethinked my position about the need of the daemon interfaces specialy about the controler part and I am ready to +1 for moving the interfaces and replace it a description of methods and classes that would be called/instancied from a native program. But I need time (about 2 weeks). I will try to provide a description of the features I need. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 3888] - WebappClassLoader: Lifecycle error : CL stopped
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888 WebappClassLoader: Lifecycle error : CL stopped [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 08:19 --- Getting this error on FreeBSD with Tomcat 4.0.3. Can't really tell why this is going on. I have four webapps running. Three websites of our clients and the default webapp. I can give many more details about this situation if you'd like, but I can't really tell what is significant in this situation, so please let me know what kind of details you need. I'd like to have it noted that in catalina.out, about a 1/4 of the entire 65000 line log file consists of WebappClassLoader: Lifecycle error : CL stopped. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: administration-howto.html
Amy Roh wrote: Glenn Nielsen wrote: jean-frederic clere wrote: Hi, I am willing to use the administration tools of Tomcat but I am wondering where the administration-howto.html is located. If it is not existing I will create one similar to the existing manager-howto.xml. Any comments? I know that Amy has been working on taking care of some of the problems I posted about the Tomcat 4.1 configuration admin application. A help document was one of the issues. There is also Tomcat Administration tool tutorial for the Java Web Services at http://java.sun.com/webservices/docs/1.0/tutorial/doc/Admintool.html. It doesn't have the latest admin addition but I'm sure you can reference to the documentation as you write the administration-howto.html in Tomcat. Perhaps, you can add a link to it as well. Thanks for good suggestion! Many thanks I was looking for a document to find how to start... You have a lot more :-)) Amy This is really needed, thanks! Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyoteAdapter.java CoyoteConnector.java
remm2002/10/10 02:07:34
Modified:coyote/src/java/org/apache/coyote/tomcat5 CoyoteAdapter.java
CoyoteConnector.java
Log:
- Remove slow and ugly 4.0.x only code.
Revision ChangesPath
1.4 +4 -105
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteAdapter.java
Index: CoyoteAdapter.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteAdapter.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- CoyoteAdapter.java4 Oct 2002 19:27:09 - 1.3
+++ CoyoteAdapter.java10 Oct 2002 09:07:33 - 1.4
@@ -286,22 +286,6 @@
// Parse session Id
parseSessionId(req, request);
-// Additional URI normalization and validation is needed for security
-// reasons on Tomcat 4.0.x
-if (connector.getUseURIValidationHack()) {
-String uri = validate(request.getRequestURI());
-if (uri == null) {
-res.setStatus(400);
-res.setMessage(Invalid URI);
-throw new IOException(Invalid URI);
-} else {
-req.requestURI().setString(uri);
-// Redoing the URI decoding
-req.decodedURI().duplicate(req.requestURI());
-req.getURLDecoder().convert(req.decodedURI(), true);
-}
-}
-
// Parse cookies
parseCookies(req, request);
@@ -391,91 +375,6 @@
}
request.setCookies(cookies);
-
-}
-
-
-/**
- * Return a context-relative path, beginning with a /, that represents
- * the canonical version of the specified path after .. and . elements
- * are resolved out. If the specified path attempts to go outside the
- * boundaries of the current context (i.e. too many .. path elements
- * are present), return codenull/code instead.
- * This code is not optimized, and is only needed for Tomcat 4.0.x.
- *
- * @param path Path to be validated
- */
-protected static String validate(String path) {
-
-if (path == null)
-return null;
-
-// Create a place for the normalized path
-String normalized = path;
-
-// Normalize /%7E and /%7e at the beginning to /~
-if (normalized.startsWith(/%7E) ||
-normalized.startsWith(/%7e))
-normalized = /~ + normalized.substring(4);
-
-// Prevent encoding '%', '/', '.' and '\', which are special reserved
-// characters
-if ((normalized.indexOf(%25) = 0)
-|| (normalized.indexOf(%2F) = 0)
-|| (normalized.indexOf(%2E) = 0)
-|| (normalized.indexOf(%5C) = 0)
-|| (normalized.indexOf(%2f) = 0)
-|| (normalized.indexOf(%2e) = 0)
-|| (normalized.indexOf(%5c) = 0)) {
-return null;
-}
-
-if (normalized.equals(/.))
-return /;
-
-// Normalize the slashes and add leading slash if necessary
-if (normalized.indexOf('\\') = 0)
-normalized = normalized.replace('\\', '/');
-if (!normalized.startsWith(/))
-normalized = / + normalized;
-
-// Resolve occurrences of // in the normalized path
-while (true) {
-int index = normalized.indexOf(//);
-if (index 0)
-break;
-normalized = normalized.substring(0, index) +
-normalized.substring(index + 1);
-}
-
-// Resolve occurrences of /./ in the normalized path
-while (true) {
-int index = normalized.indexOf(/./);
-if (index 0)
-break;
-normalized = normalized.substring(0, index) +
-normalized.substring(index + 2);
-}
-
-// Resolve occurrences of /../ in the normalized path
-while (true) {
-int index = normalized.indexOf(/../);
-if (index 0)
-break;
-if (index == 0)
-return (null); // Trying to go outside our context
-int index2 = normalized.lastIndexOf('/', index - 1);
-normalized = normalized.substring(0, index2) +
-normalized.substring(index + 3);
-}
-
-// Declare occurrences of /... (three or more dots) to be invalid
-// (on some Windows platforms this walks the directory tree!!!)
-if (normalized.indexOf(/...) = 0)
-return (null);
-
-// Return the normalized path that we have completed
-return (normalized);
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 Constants.java CoyoteRequest.java CoyoteResponse.java
remm2002/10/10 02:45:30
Modified:coyote/src/java/org/apache/coyote/tomcat5 Constants.java
CoyoteRequest.java CoyoteResponse.java
Log:
- Recycle facades when not using the security manager (this will be
refactored further).
Revision ChangesPath
1.3 +6 -0
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/Constants.java
Index: Constants.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/Constants.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Constants.java21 Sep 2002 05:36:52 - 1.2
+++ Constants.java10 Oct 2002 09:45:30 - 1.3
@@ -87,4 +87,10 @@
*/
public static final String SSL_CERTIFICATE_ATTR =
org.apache.coyote.request.X509Certificate;
+/**
+ * Security flag.
+ */
+protected static final boolean SECURITY =
+(System.getSecurityManager() != null);
+
}
1.5 +5 -5
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequest.java
Index: CoyoteRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequest.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- CoyoteRequest.java21 Sep 2002 05:36:52 - 1.4
+++ CoyoteRequest.java10 Oct 2002 09:45:30 - 1.5
@@ -422,7 +422,7 @@
parameterMap.setLocked(false);
parameterMap.clear();
-if (facade != null) {
+if ((Constants.SECURITY) (facade != null)) {
facade.clear();
facade = null;
}
1.9 +5 -5
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java
Index: CoyoteResponse.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- CoyoteResponse.java 4 Oct 2002 03:36:27 - 1.8
+++ CoyoteResponse.java 10 Oct 2002 09:45:30 - 1.9
@@ -315,7 +315,7 @@
error = false;
cookies.clear();
-if (facade != null) {
+if ((Constants.SECURITY) (facade != null)) {
facade.clear();
facade = null;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 3888] - WebappClassLoader: Lifecycle error : CL stopped
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888 WebappClassLoader: Lifecycle error : CL stopped --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 09:51 --- Hey Remy, You say it is a user error. The only reasonable user error I can find, is that the placing of our lib files might leave something to question. Let me explain: We have one big web application. A Content Management System we're developing. Whenever we build a project using this Content Management System, we use the latest stable release of the thing. Since new versions of libraries we have not created come out all the time, we have the libraries in our web application also. This so that when we build our project, we have those versions of certain libraries that are compatible with our project. This does mean, that when we use for example log4j on one server, we do not place it in $Tomcat/common/lib or $tomcat/lib but in every web-app's WEB-INF/lib directory. As said, I know this is not a usage that the Tomcat documentation promotes. I do however feel, that IF this is the reason Tomcat's classloaders are crashing, this should not be possible to happen. If this is NOT the user error you're talking about, then please explain what you do mean. I've read the servlet spec, and read the tomcat documentation. If I don't know, that means a whole hell of a lot of people don't know either. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13285] - admin web application fail with virtual host
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13285. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13285 admin web application fail with virtual host --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 11:09 --- It is the same problem in tomcat 3.3.2-dev on today. So, I investigate and try to fix it. For the roadmap, Larry says to me that, likely, such a plan will be done for at least a month ... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 3888] - WebappClassLoader: Lifecycle error : CL stopped
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888 WebappClassLoader: Lifecycle error : CL stopped --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 11:36 --- About the library placement, you're free to do whatever you want, and we're not promoting that you move it somewhere else. You have to make sure that the lifecycle of the object you create and resources you allocate (threads for example) are synced with the webapp lifecycle. When there's a restart you have to destroy all leftover objects, and recreate them when the webapp is initialized again. You get the errors when some object which was loaded by the old webapp classloader tries to run code. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
remm2002/10/10 07:35:22
Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
Log:
- Throw an error if trying to use a stopped classloader.
Revision ChangesPath
1.7 +5 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
Index: WebappClassLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- WebappClassLoader.java5 Sep 2002 11:38:59 - 1.6
+++ WebappClassLoader.java10 Oct 2002 14:35:21 - 1.7
@@ -1195,7 +1195,7 @@
// Don't load classes if class loader is stopped
if (!started) {
log(Lifecycle error : CL stopped);
-throw new ClassNotFoundException(name);
+throw new IncompatibleClassChangeError(name);
}
// (0) Check our previously loaded local class cache
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13497] New: - workDir parameter in server.xml context is ignored by Tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13497. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13497 workDir parameter in server.xml context is ignored by Tomcat Summary: workDir parameter in server.xml context is ignored by Tomcat Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] According to http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/context.html, workDir specifies the Pathname to a scratch directory to be provided by this Context for temporary read-write use by servlets within the associated web application. If not specified, a suitable directory underneath $CATALINA_HOME/work will be provided. When I specify this parameter in my context (as shown below), it is ignored and all files continue to be written to the $CATALINA_HOME/work directory. Context path=/myapp docBase=myapp workDir=/myapp/otherwork / -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13497] - workDir parameter in server.xml context is ignored by Tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13497. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13497 workDir parameter in server.xml context is ignored by Tomcat [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Normal --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 14:51 --- I looked at the code briefly. It looks fine, and it doesn't look the value is getting overwritten. That being said, maybe you should try to investigate it and submit a patch if you find something, as I doubt many people are using the feature. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13499] New: - Jasper throws an exception on an immediate pageContext.forward()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13499. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13499 Jasper throws an exception on an immediate pageContext.forward() Summary: Jasper throws an exception on an immediate pageContext.forward() Product: Tomcat 4 Version: Unknown Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] For starters, I'm using Jetty, not Tomcat, and have no way to test this in Tomcat. Here's a copy of my test.jsp: --- %@ page buffer=none % % pageContext.forward(/index.jsp; % --- In Jetty, this results in the following: java.lang.IllegalStateException: Illegal to clear() when buffer size == 0 at org.apache.jasper.runtime.JspWriterImpl.clear(JspWriterImpl.java:184) at org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:410) Since buffer=none, this seems to be a semantically correct exception, but it doesn't make any sense -- why would this combination be illegal? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13499] - Jasper throws an exception on an immediate pageContext.forward()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13499. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13499 Jasper throws an exception on an immediate pageContext.forward() [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Minor --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 15:54 --- And you have something against using a buffer (which should be faster) ? Otherwise, it's quite clear why it happens: forward resets the response (well, the buffer since it's JSP), and clearing the non existing buffer raises the ISE. So not using a buffer is currently not supported at all. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13254] - Page compilation errors missing resource entries
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13254. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13254 Page compilation errors missing resource entries --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 15:55 --- Created an attachment (id=3411) Test file that produces the erroneous exception report -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13392] - When tag pooling is enabled, release() is not called on tag instances
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392 When tag pooling is enabled, release() is not called on tag instances [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 15:56 --- Referencing the spec for this functionality is not applicable since it doesn't cover the lifecycle with respect to tag pooling. I consider it 'practical' to reset a tag prior to re-using it in the tag pooling feature. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13254] - Page compilation errors missing resource entries
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13254. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13254 Page compilation errors missing resource entries --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 15:56 --- The attached file is an erroneously created JSP that causes the exception report provided. The exception report is obviously a secondary exception caused by a missing error string property. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13499] - Jasper throws an exception on an immediate pageContext.forward()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13499. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13499 Jasper throws an exception on an immediate pageContext.forward() [EMAIL PROTECTED] changed: What|Removed |Added Severity|Minor |Major --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 16:01 --- Sure. Like I said, the exception makes semantic sense. But there's nothing in the spec, that I see, that implies this *should* be illegal. If it *is* illegal by spec, I'm more than willing to fix my code. For the record, I *do* use a buffer. But I set it on the servlet level, in a base class that all my JSPs extend. A quick reading of your comment implies that the spec has no problem with this, but the current implementation of Jasper 2 can't handle this (entirely legal) case. As I said, I'm more than happy to fix my code if it's wrong, but it's a little annoying to change upwards of 900 JSPs if it's something that Jasper can, and should, be fixed to handle. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: commons-daemon release ?
Costin Manolache wrote: jean-frederic clere wrote: As I said, for 'chuid' functionality I prefer using a direct call - I have most of it implemented using jk2, I'll finish this well before 5.0 is released. I prefer to have a C wrapper that start the JVM and call methods than having the reverse. That's perfectly fine as long as you accept that others may have different preferences :-) I agree that a C wrapper to start the VM may be better than the current .sh - but again I disagree on using JNI invocation instead of a simple exec to start the VM ( for the simple reason that Kaffe and GCJ don't support invocation - at least last time I checked ). Having both in the same executable may not be necessary but a lot of native code could be shared. The C code (mostly written by Pier) is quite easy to follow and well structured. The environment to set before JNI_CreateJavaVM() or exec(java) is very similar. About invocation, I do not know about Kaffe and I will check for gcj. I have rethinked my position about the need of the daemon interfaces specialy about the controler part and I am ready to +1 for moving the interfaces and replace it a description of methods and classes that would be called/instancied from a native program. But I need time (about 2 weeks). I will try to provide a description of the features I need. If the daemon is not forcing tomcat to implement any interface - you have my -0 on the release. Ok but I need time. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13392] - When tag pooling is enabled, release() is not called on tag instances
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392 When tag pooling is enabled, release() is not called on tag instances [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 16:08 --- I suggest you patch Jasper to implement the behavior you'd like, then ;-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13392] - When tag pooling is enabled, release() is not called on tag instances
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392 When tag pooling is enabled, release() is not called on tag instances [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
List Archive: Follow-up - jk2 jni doesn't work
Jean-Frederic, Bill, Mladen Turk, List,
I found this in the archive -- was this resolved? The code snippet
OPT=-Djava.class.path=${TOMCAT_HOME}\bin\tomcat-jni.jar;${TOMCAT_HOME}\serve
r\lib\commons-logging.jar
What file did this get added to? I'm having *THIS* exact problem -- and
haven't been able to resolve it, I've built the connectors and
jakarta-tomcat-4.1.12 from src with no errors/problems but can't get the APR
to init because of the java.lang.NoClassDefFoundError in AprImpl.java.
I would like to get this working -- work-around is what I'm looking for,
please help.
Paul
From the archive:
Re: [BUG] jk2 jni doesn't work
From: jean-frederic clere
Subject: Re: [BUG] jk2 jni doesn't work
Date: Wed, 18 Sep 2002 23:41:39 -0700
Mladen Turk wrote:
This is the classloader problem.
Think that Bill Baker is solving this, but until then add the
commons-logging.jar to the loaded classes when started inprocess:
OPT=-Djava.class.path=${TOMCAT_HOME}\bin\tomcat-jni.jar;${TOMCAT_HOME}\s
erver\lib\commons-logging.jar
I do not like this work-around: we will have end with a huge classpath.
Adding commons-logging to the classpath solves the JNI problem.
Bill, when can ve expect this will get solved?
java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at org.apache.jk.apr.AprImpl.clinit(AprImpl.java:348)
java.lang.NoClassDefFoundError
MT.
--
mailto:[EMAIL PROTECTED]
Enterprise Distributed Capabilities
EDS Corporation
248-265-8283
Paul J. Brzezinski ([EMAIL PROTECTED]).vcf
Description: Binary data
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13392] - When tag pooling is enabled, release() is not called on tag instances
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392 When tag pooling is enabled, release() is not called on tag instances [EMAIL PROTECTED] changed: What|Removed |Added Status|CLOSED |REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 16:32 --- My preference is to have this fixed in the base release and to tell our customers that Tomcat works fine and that the tag pooling functionality works well with their applications without diabling this key feature. Why are you against such a practical change? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13502] New: - Memory leak on session
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13502. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13502 Memory leak on session Summary: Memory leak on session Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have a application which have a special command which connect to the web application by http (open an xsp file). This http request uses an authentication and put somes values in session (login, password, ...). With a profiler, I can see that each time I execute this command, these values are added in a hashMap in [...].catalina.session.StandardSession.setAttribute (variable 'attributes'). This HashMap does'nt seems cleared. I saw this bug on tomcat-4.0.1 and 4.0.6. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13502] - Memory leak on session
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13502. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13502 Memory leak on session [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 17:03 --- This should be cleared only when the session is passivated, which by default takes some time. If you see something wrong from that mechanism, reopen the bug giving more details, but there's nothing wrong with what you describe. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13503] New: - JspParseEventListener.java outputs broken setContentType(...) row
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13503.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13503
JspParseEventListener.java outputs broken setContentType(...) row
Summary: JspParseEventListener.java outputs broken
setContentType(...) row
Product: Tomcat 4
Version: 4.0.4 Final
Platform: All
OS/Version: All
Status: NEW
Severity: Major
Priority: Other
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
The version is 4.0.6 as opposed to 4.0.4 Final (4.0.6 was not available in the
Version list):
From org.apache.jasper.compiler.JspParseEventListener.java:
162: defaultType = text/html;;
163: defaultCharset = ISO-8859-1;
...
362: // Per errata_a, determine the default output content type
363:if (servletContentType == null) {
364:servletContentType = defaultType +
365: ((pageEncoding == null)? defaultCharset: pageEncoding);
366:}
367:writer.println(response.setContentType(
378: + writer.quoteString(servletContentType)
369: + ););
This produces the following line of code to the compiled JSP .java file
response.setContentType(text/html;ISO-8859-1);
I propose that this is not correct, but should instead be:
response.setContentType(text/html;charset=ISO-8859-1);
The fix is to change row 364 to be:
364:servletContentType = defaultType + charset= +
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 3888] - WebappClassLoader: Lifecycle error : CL stopped
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888 WebappClassLoader: Lifecycle error : CL stopped [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Blocker Status|RESOLVED|REOPENED Priority|Other |High Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 17:28 --- You get the errors when some object which was loaded by the old webapp classloader tries to run code. Ah...this is the first time you have specified when the error occurs. Now, if the classloader has been properly destroyed (generally you need to set it to be null), why is the old code even able to run? Since the old code is loaded in the now null classloader, then the JVM should not allow that code to run. Maybe there is classloader caching going on (ie: the reference to the old classloader is not being properly destoryed)? Also, I still say this is a bug in Tomcat's classloader system because I have been doing servlet development for years (this bug is now more than a year old) with several different servlet containers and have never seen this bug. In fact, it didn't start happening until I had started using that version of Tomcat 4. Also, I still see this bug still happens all the time for me...even with the 4.0.6 version of Tomcat. Remy, something is broken and it isn't user error. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 3888] - WebappClassLoader: Lifecycle error : CL stopped
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888 WebappClassLoader: Lifecycle error : CL stopped --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 17:37 --- Hhmm, sorry, but I can't force finalization of objects, and the VM will indeed allow code to continue running (which is normal since the old CL is not actually destroyed). The old CL will not get finalized either since the objects in question still reference it through their classdef. Waiting for your patch to fix it (and I'll be handling some other issues meanwhile) :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8752] - HTTPS redirect fails if using welcome-file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8752. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8752 HTTPS redirect fails if using welcome-file --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 17:40 --- This problem still exists in 4.1.12 as well. Duplicated same as original reporter. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: List Archive: Follow-up - jk2 jni doesn't work
-Original Message-
From: Brzezinski, Paul J [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 10, 2002 6:25 PM
To: [EMAIL PROTECTED]
Subject: List Archive: Follow-up - jk2 jni doesn't work
Jean-Frederic, Bill, Mladen Turk, List,
I found this in the archive -- was this resolved? The code snippet
Think not.
OPT=-Djava.class.path=${TOMCAT_HOME}\bin\tomcat-jni.jar;${TOMC
AT_HOME}\serve
r\lib\commons-logging.jar
What file did this get added to?
workers2.properties
I'm having *THIS* exact
problem -- and haven't been able to resolve it, I've built
the connectors and jakarta-tomcat-4.1.12 from src with no
errors/problems but can't get the APR to init because of the
java.lang.NoClassDefFoundError in AprImpl.java.
I would like to get this working -- work-around is what I'm
looking for, please help.
You will also need the
handler.list=apr,request,container,channelJni
apr.jniModeSo=inprocess
In the jk2.properties.
Paul
From the archive:
Re: [BUG] jk2 jni doesn't work
--
--
From: jean-frederic clere
Subject: Re: [BUG] jk2 jni doesn't work
Date: Wed, 18 Sep 2002 23:41:39 -0700
--
--
Mladen Turk wrote:
This is the classloader problem.
Think that Bill Baker is solving this, but until then add the
commons-logging.jar to the loaded classes when started inprocess:
OPT=-Djava.class.path=${TOMCAT_HOME}\bin\tomcat-jni.jar;${TOMCAT_HOME}
\s
erver\lib\commons-logging.jar
I do not like this work-around: we will have end with a huge
classpath.
Adding commons-logging to the classpath solves the JNI problem.
Bill, when can ve expect this will get solved?
java.lang.NoClassDefFoundError:
org/apache/commons/logging/LogFactory
at org.apache.jk.apr.AprImpl.clinit(AprImpl.java:348)
java.lang.NoClassDefFoundError
MT.
--
mailto:[EMAIL PROTECTED]
Enterprise Distributed Capabilities
EDS Corporation
248-265-8283
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13504] New: - InstallTask fails while DeployTask succeeds
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13504.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13504
InstallTask fails while DeployTask succeeds
Summary: InstallTask fails while DeployTask succeeds
Product: Tomcat 4
Version: 4.1.12
Platform: Macintosh
OS/Version: MacOS X
Status: NEW
Severity: Blocker
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I tried the examples in Professional Apache Tomcat from wrox to install/deploy
applications with ant. The following script fails if I try to install the
application:
target name=install description=Install web application
install url=${url} username=${username} password=${password}
path=${path} war=file:${build}/hello.war/
/target
target name=deploy description=Deploy web application depends=build
deploy url=${url} username=${username} password=${password}
path=${path} war=file:${build}/hello.war/
/target
[arenal:Tomcat/wrox/hello] cyrill% ant install
Buildfile: build.xml
install:
[install] FAIL - Encountered exception java.io.IOException:
java.lang.IllegalArgumentException: Doc base must point to a WAR file
BUILD FAILED
file:/Users/cyrill/Documents/Tomcat/wrox/hello/build.xml:48: FAIL - Encountered
exception java.io.IOException: java.lang.IllegalArgumentException: Doc base must
point to a WAR file
Total time: 2 seconds
In the logs, I found the following output:
2002-10-10 14:30:16 Manager: install: Installing web application at '/hello'
from 'file:/Users/cyrill/Documents/Tomcat/wrox/hello/build/hello'
2002-10-10 14:30:16 StandardHost[localhost]: Installing web application at
context path /hello from URL
file:/Users/cyrill/Documents/Tomcat/wrox/hello/build/hello
2002-10-10 14:30:16 StandardHost[localhost]: Error deploying application at
context path /hello
java.lang.IllegalArgumentException: Document base
/Users/cyrill/Documents/Tomcat/wrox/hello/build/hello does not exist or is not a
readable directory
at
org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.java:193)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3397)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:821)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:579)
at
org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:257)
at org.apache.catalina.core.StandardHost.install(StandardHost.java:772)
at
org.apache.catalina.servlets.ManagerServlet.install(ManagerServlet.java:650)
at
org.apache.catalina.servlets.ManagerServlet.doGet(ManagerServlet.java:342)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:527)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2396)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
[5.0] 5.0.0 tag
Is tagging 5.0.0 ok ? I did some profiling on 5.0, and committed some optimizations. The biggest problem by far is the mapper (which thanks to the new welcome files code is much much worse than 4.1's mapper). I plan to rewrite the mapper for inclusion in 5.0.1. This will introduce some changes (additions) in the Request API, as well as starting to actually use the j-t-c/util buffers in the main pipeline. Real world performance will likely be quite good when that is done (the sendRedirect abuse Tomcat currently suffers from is likely putting some strain on the servers). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13504] - InstallTask fails while DeployTask succeeds
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13504. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13504 InstallTask fails while DeployTask succeeds [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 17:51 --- You should read the docs (manager app howto). Install, unlike deploy, uses jar:...!/ URLs. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 3888] - WebappClassLoader: Lifecycle error : CL stopped
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888 WebappClassLoader: Lifecycle error : CL stopped --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 17:55 --- Well, that is the problem...the old CL is not destroyed. Why is it not set to null? -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13223] - JSP pages in XML syntax do not compile properly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13223. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13223 JSP pages in XML syntax do not compile properly --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 17:57 --- I assume jsp:element is defined in a newer version of the spec than the publicly available 2.0 PFD? I couldn't find it anywhere. Although using jsp:element seems a bit cumbersome, it's definitely a great improvement over JSP 1.2! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 3888] - WebappClassLoader: Lifecycle error : CL stopped
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888 WebappClassLoader: Lifecycle error : CL stopped --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 17:59 --- Catalina replaces the pointer from the old loader to the new one, removes sessions and things. However, you could have a thread or some other component holding the pointer to the objects, and preventing finalization. Basically, if you can find some component in Catalina holding a pointer to either one of the old object/classes/classloader, then the bug is valid. Otherwise, it's not. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.properties.default
remm2002/10/10 11:00:16
Modified:.build.properties.default
Log:
- Switch to Struts 1.1-b2.
Revision ChangesPath
1.41 +4 -4 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- build.properties.default 7 Oct 2002 15:03:10 - 1.40
+++ build.properties.default 10 Oct 2002 18:00:16 - 1.41
@@ -221,11 +221,11 @@
puretls.jar=${puretls.lib}/puretls.jar
-# - Struts, version 1.0.2 or later -
-struts.home=${base.path}/jakarta-struts-1.0.2
+# - Struts, version 1.1 Beta 2 or later -
+struts.home=${base.path}/jakarta-struts-1.1-b2
struts.lib=${struts.home}/lib
struts.jar=${struts.lib}/struts.jar
-struts.loc=http://jakarta.apache.org/builds/jakarta-struts/release/v1.0.2/jakarta-struts-1.0.2.tar.gz
+struts.loc=http://jakarta.apache.org/builds/jakarta-struts/release/v1.1-b2/jakarta-struts-1.1-b2.tar.gz
# - Tyrex Data Source, version 1.0 -
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 3888] - WebappClassLoader: Lifecycle error : CL stopped
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888 WebappClassLoader: Lifecycle error : CL stopped --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 18:10 --- If you null out the classloader, then all of the pointers become invalid because the classloader is the top pointer. Again, the problem is the fact that you don't null out the classloader. I would like you to ask on jsr-053 if any other vendors have this problem. I bet you some beers at my nightclub that they don't. This is a tomcat specific problem. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: apps conversion from 3.3.1 to 4.1.12
On Thu, 10 Oct 2002, Henri Gomez wrote: Date: Thu, 10 Oct 2002 08:10:03 +0200 From: Henri Gomez [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: apps conversion from 3.3.1 to 4.1.12 If this reference is in your web.xml file, then my suggestion is already being done. To test it, try temporarily copying the settings.xml file into the WEB-INF directory and changing the relative URL appropriately. Putting the file in WEB-INF works, even if I use ../settings, ie directly in webapps/ROOT. I'd be -1 on removing the security check in 4.x/5.x. Fixing 3.3.2 sounds like a good idea. I'll be -1 to fix the 3.3.2 for many reasons : - It will brake all deployment strategy - I'm still not sure it's a security problem since nobody prevent you to change to PUBLIC and goes outside : !ENTITY % settings SYSTEM ../../../settings.xml %settings; to !ENTITY % settings PUBLIC hackme http://hackme.com/settings.xml; %settings; That's more than insecure isn't it ? Not if you put the settings file inside /WEB-INF where it is not accessible to external clients. I take a look in specs and didn't see anything preventing you to have entities located outside WEBAPP so I feel it's a regression and not a security feature. Ad minima, in TC 4.x and 5.x, there should be a setting in web.xml, or server.xml to enable this behaviour even if it's prevented by default. -1, for at least three reasons: * Such a path is non-sensical when you run webapps directly from WAR files, because the base resource (inside the WAR) does not have a file path. * The URL to the base resource is being handled by a URLStreamHandler provided by the servlet container (the jndi: prefix in Tomcat 4), and the spec disallows access to resources outside the WAR. * The behavior you describe would allow any webapp to snoop the entire directory structure of your server with a suitably construced relative path. *You* may be running on an OS that supports access permissions (and understand how to use them), but that doesn't help the poor sod who uses something like Win98. Keep in mind that if it works here, it will also would work on something like: InputStream stream = getServletContext().getResourceAsStream(../../../etc/passwd); with some suitable number of .. depending on where you've got Tomcat installed. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13254] - Page compilation errors missing resource entries
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13254. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13254 Page compilation errors missing resource entries [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 18:33 --- Problem already fixed. See log for org.apache.jasper.compiler.DefaultErrorHandler: revision 1.2 date: 2002/07/24 19:58:57; author: luehe; state: Exp; lines: +11 -6 added error message for jsp.error.parse.xml.scripting.invalid.body error code + fixed NPE in ErrorDispatcher With that fix, you get this exception when accessing the page: org.apache.jasper.JasperException: null(16,92) The value of attribute value must not contain the '' character. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jk2 and daemon ( was Re: commons-daemon release ?)
As I mentioned, there's a lot of duplication - and likely we'll see more. I don't see this as a major problem - duplication is sometimes good. It would be however nice to have similar behavior when possible and make sure we pick each other's fixes. The areas of duplication: - starting and embeded machine using JNI. The code seems similar, I did reviewed it in daemon and didn't find anything to grab - but more eyes to look at the code would help. - starting a VM using exec / monitor the child process. It is not implemented yet in jk2 - but pretty important ( it's one of the features from jserv that wasn't yet ported). It seems daemon has a bit of code - as I mentioned from reading it I don't think it works, and it would be better to use the code from jserv for this - whenever we do implement this. - configuration for started processes. Daemon is using CLI, jk uses a file - nothing to do here ( but it would be good if daemon would use properties too ). - Win32 services. This is not yet ported to jk2 - and I'm not sure what to do about jk_nt_service. It works very well, but the code is messy. It would be worth adding a jk2 component in the style of the win32 event log. - chuid/kill. The code in daemon seems very good - that's what I'm using for jk2_user ( I'll check it in after I test more ). As Mladen mentioned, it may be usefull to have an asynchronous channel between tomcat and the web server. It is also very usefull to add the 'monitor/exec' features from jserv. And if we integrate the features from nt_service, jk2 will have all the code that's needed for launching. So it may be worth adding a small 'main()' to jk2. It would read a config - including components that would start/monitor tomcats, async communication, manage the shmem ( so that tomcat doesn't have to use JNI ), etc. Most of the code is already available - in either daemon or jserv. The main questions are 'when' and 'who'. For the first - I suspect not the near future, unless more people are interested and volunteer for the 'who' part :-) -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jk2 and daemon ( was Re: commons-daemon release ?)
Costin Manolache [EMAIL PROTECTED] wrote: - starting a VM using exec / monitor the child process. It is not implemented yet in jk2 - but pretty important ( it's one of the features from jserv that wasn't yet ported). It seems daemon has a bit of code - as I mentioned from reading it I don't think it works, and it would be better to use the code from jserv for this - whenever we do implement this. That was the feature which created more problems in JServ... I remember me and Ed hammering on it for months in 97/98. My hint, forget about it, also because if you tie it to the web server process, when you take down the Web Server, also your servlet engine is going to go down, and that's not a very desirable feature given how much time it takes to initialize 7/8 web applications Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: List Archive: Follow-up - jk2 jni doesn't work
List, MT -
Added the extra OPT stuff to workers2.properties and apache 2.0 starts up
OK.
Still having errors though when I start Tomcat:
Oct 10, 2002 2:52:54 PM org.apache.commons.modeler.Registry loadRegistry
INFO: Loading registry information
Oct 10, 2002 2:52:54 PM org.apache.commons.modeler.Registry getRegistry
INFO: Creating new Registry instance
Oct 10, 2002 2:52:57 PM org.apache.commons.modeler.Registry getServer
INFO: Creating MBeanServer
Oct 10, 2002 2:53:03 PM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on port 8080
Starting service Tomcat-Standalone
Apache Tomcat/4.1.12-LE-jdk14
Oct 10, 2002 2:53:30 PM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on port 8080
Oct 10, 2002 2:53:30 PM org.apache.jk.server.JkMain newHandler
SEVERE: Can't create apr
java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at org.apache.jk.apr.AprImpl.clinit(AprImpl.java:340)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:130)
.
.
.
.
Any ideas?
--
mailto:[EMAIL PROTECTED]
Enterprise Distributed Capabilities
EDS Corporation
248-265-8283
: -Original Message-
: From: Mladen Turk [mailto:[EMAIL PROTECTED]]
: Sent: Thursday, October 10, 2002 1:42 PM
: To: 'Tomcat Developers List'
: Subject: RE: List Archive: Follow-up - jk2 jni doesn't work
:
:
:
:
: -Original Message-
: From: Brzezinski, Paul J [mailto:[EMAIL PROTECTED]]
: Sent: Thursday, October 10, 2002 6:25 PM
: To: [EMAIL PROTECTED]
: Subject: List Archive: Follow-up - jk2 jni doesn't work
:
:
: Jean-Frederic, Bill, Mladen Turk, List,
:
: I found this in the archive -- was this resolved? The code snippet
:
:
: Think not.
:
: OPT=-Djava.class.path=${TOMCAT_HOME}\bin\tomcat-jni.jar;${TOMC
: AT_HOME}\serve
: r\lib\commons-logging.jar
:
: What file did this get added to?
:
: workers2.properties
:
: I'm having *THIS* exact
: problem -- and haven't been able to resolve it, I've built
: the connectors and jakarta-tomcat-4.1.12 from src with no
: errors/problems but can't get the APR to init because of the
: java.lang.NoClassDefFoundError in AprImpl.java.
:
: I would like to get this working -- work-around is what I'm
: looking for, please help.
:
:
: You will also need the
: handler.list=apr,request,container,channelJni
: apr.jniModeSo=inprocess
:
: In the jk2.properties.
:
: Paul
:
: From the archive:
:
: Re: [BUG] jk2 jni doesn't work
:
: --
: --
:
:
: From: jean-frederic clere
: Subject: Re: [BUG] jk2 jni doesn't work
: Date: Wed, 18 Sep 2002 23:41:39 -0700
:
: --
: --
:
:
: Mladen Turk wrote:
: This is the classloader problem.
:
: Think that Bill Baker is solving this, but until then add the
: commons-logging.jar to the loaded classes when started inprocess:
:
:
:
: OPT=-Djava.class.path=${TOMCAT_HOME}\bin\tomcat-jni.jar;${TOMCAT_HOME}
: \s
: erver\lib\commons-logging.jar
:
: I do not like this work-around: we will have end with a huge
: classpath.
:
:
: Adding commons-logging to the classpath solves the JNI problem.
:
: Bill, when can ve expect this will get solved?
:
:
:
:
: java.lang.NoClassDefFoundError:
: org/apache/commons/logging/LogFactory
:at org.apache.jk.apr.AprImpl.clinit(AprImpl.java:348)
: java.lang.NoClassDefFoundError
:
:
:
:
: MT.
:
:
:
:
:
: --
: mailto:[EMAIL PROTECTED]
: Enterprise Distributed Capabilities
: EDS Corporation
: 248-265-8283
:
:
:
:
:
: --
: To unsubscribe, e-mail:
: mailto:tomcat-dev-: [EMAIL PROTECTED]
: For
: additional commands,
: e-mail: mailto:[EMAIL PROTECTED]
:
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13506] New: - Tomcat 4.1.12 Proxy inconsistent behavior
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13506. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13506 Tomcat 4.1.12 Proxy inconsistent behavior Summary: Tomcat 4.1.12 Proxy inconsistent behavior Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Blocker Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have an Apache server configured to proxy requests to another server on port 80/test (e.g. http://saturn/test) to http://europa:8082. The problem is that Tomcat is inconsistently managing the requests. When I initially log into my tomcat app, it can find a few pages but not all of them. Then after (literally) clicking a few links, the missing pages all of a sudden begin to appear. Once it works, everything is fine, until I close the session, then the problem reappears. There are no errors in either the Apache or Tomcat logs. I've tried both Apache 1.3 and 2.0 and problem is consistent with both.. leaving me to believe it is isolated to Tomcat, also Tomcat not proxied, my app works fine. My hypothesis is that the proxy name is not always visible. It seems that when it doesn't work, the server name is not attached to the URL. Supporting information: Port 8082 is configured in my server.xml file as follows: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8082 minProcessors=5 maxProcessors=75 enableLookups=true acceptCount=10 debug=9 connectionTimeout=2 proxyPort=80 proxyName=saturn/test useURIValidationHack=false / I have Apache configured to proxy, exactly as the Tomcat documentation specifies, that is: ProxyPass/test http://europa:8082 ProxyPassReverse /test http://europa:8082 I'm running in a Windows 2000/NT environment. I have not been able to ascertain any additional information. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13392] - When tag pooling is enabled, release() is not called on tag instances
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392 When tag pooling is enabled, release() is not called on tag instances --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 19:16 --- Juan wrote: Referencing the spec for this functionality is not applicable since it doesn't cover the lifecycle with respect to tag pooling. Sure it does! When the spec mentions that there may be multiple invocations on doStartTag() and doEndTag() in between [calling release()], it does consider tag pooling. How else could doStartTag() and doEndTag() be called multiple times on the same tag handler, if the tag handler were not reused? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13506] - Tomcat 4.1.12 Proxy inconsistent behavior
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13506. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13506 Tomcat 4.1.12 Proxy inconsistent behavior [EMAIL PROTECTED] changed: What|Removed |Added Priority|Other |High -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 13392] - When tag pooling is enabled, release() is not called on tag instances
I'm not sure what all the debate is over. Since you know for sure doStartTag() will be called, couldn't your tag call .release() as the first thing it does in doStartTag()? Wouldn't that easily solve the problem? since the spec does cover the issue as Jan pointed out, having doStartTag() call release() would be an quick and easy fix. maybe I'm just over simplifying the problem. peter lin [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392 When tag pooling is enabled, release() is not called on tag instances [EMAIL PROTECTED] changed: What|Removed |Added Status|CLOSED |REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 16:32 --- My preference is to have this fixed in the base release and to tell our customers that Tomcat works fine and that the tag pooling functionality works well with their applications without diabling this key feature. Why are you against such a practical change? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jk2 and daemon ( was Re: commons-daemon release ?)
Pier Fumagalli wrote: Costin Manolache [EMAIL PROTECTED] wrote: - starting a VM using exec / monitor the child process. It is not implemented yet in jk2 - but pretty important ( it's one of the features from jserv that wasn't yet ported). It seems daemon has a bit of code - as I mentioned from reading it I don't think it works, and it would be better to use the code from jserv for this - whenever we do implement this. That was the feature which created more problems in JServ... I remember me and Ed hammering on it for months in 97/98. My hint, forget about it, also because if you tie it to the web server process, when you take down the Web Server, also your servlet engine is going to go down, and that's not a very desirable feature given how much time it takes to initialize 7/8 web applications I know about this - and I wasn't thinking to implement it in the same way ( i.e. have the web server directly start/stop tomcat ). The 'feature' is that all tomcat processes ( and you may run more than one in a load balanced mode ) can be started automatically and monitored. If one dies, it'll be automatically restarted. To make things interesting, this information ( and other like that ) needs to be communicated to apache servers ( to stop sending requests to not-ready servers ), and potentially to an eventual JMX proxy. This is the kind of 'control channel' that was proposed several times and will have to be implemented for other purposes. Having apache directly start/stop tomcat is not the best idea - it can just check if a 'jk2_main' process is started ( the 'communication controler' or monitor ) and launch it if not - but without stoping it if apache stops or having any further relation except normal communication. So there are separate issues - the most important beeing the startup of tocmat(s) automatically ( like jserv - but not strictly tied to apache process lifecycle ). -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13497] - workDir parameter in server.xml context is ignored by Tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13497. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13497 workDir parameter in server.xml context is ignored by Tomcat --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 19:49 --- I use the workDir attribute in the Host config and it works fine there. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: apps conversion from 3.3.1 to 4.1.12
Craig R. McClanahan wrote: Keep in mind that if it works here, it will also would work on something like: InputStream stream = getServletContext().getResourceAsStream(../../../etc/passwd); with some suitable number of .. depending on where you've got Tomcat installed. And of course, someone could just write InputStream stream=new FileInputStrea(/etc/passwd) and not bother with any ... Same for any other processing done with jdni: URL paths or not. I agree however that people shouldn't rely on resources outside a webapplication + relative paths - that's just bad programming in this environment. But it has nothing to do with security - the only way to protect against access to resources is to use a sandbox. If you don't - _anything_ is possible for the user ( including System.execute(rm -rf /)). Any restrictions on the grounds that it 'increase security' are wrong and just give a false sense of security ( which is pretty dangerous in itself). I am -1 on fixing this on 3.3 - but +1 on adding some documentation/readme that using this feature is not portable and will not work on other containers. -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 3888] - WebappClassLoader: Lifecycle error : CL stopped
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888 WebappClassLoader: Lifecycle error : CL stopped --- Additional Comments From [EMAIL PROTECTED] 2002-10-10 20:35 --- I'll need some help finding out where I should null it out (WebappLoader.stop() should be doing that, and the CL is also removed from the bindings table). Sorry Jon, I'm just too stupid to figure it out :-( -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13513] New: - There is no way to turn off Session persistence.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13513. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13513 There is no way to turn off Session persistence. Summary: There is no way to turn off Session persistence. Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Tou can use the Manager setting in your server.xml to change the 'pathname' value .. but there is no way to disable the feature .. by setting pathname to null. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13515] New: - Presistent Sessions are loaded before the Servlet is initialized.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13515. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13515 Presistent Sessions are loaded before the Servlet is initialized. Summary: Presistent Sessions are loaded before the Servlet is initialized. Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Presistent Sessions are loaded before the Servlet is initialized. This is problematic for obvious/various reasons. The servlet needs a chance to setup the various 'system's involved within the servlet .. before the sessions (and thier servlet related objects) are loaded. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13516] New: - Servlet Specification Incompatibility - Sessions are not correctly scoped according to the Servlet Specification
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13516. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13516 Servlet Specification Incompatibility - Sessions are not correctly scoped according to the Servlet Specification Summary: Servlet Specification Incompatibility - Sessions are not correctly scoped according to the Servlet Specification Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Section SRV.7.3 of the Servlet spec states the following: ..if a servlet uses the RequestDispatcher to call a servlet in another web application, any sessions created for and visible to the callee servlet must be different from those visible to the calling servlet. Both Tomcat 4.0.4 and 4.1.9 do not adhere to this requirement. When an include () is performed across web applications, the session is the same. An attribute placed in the session of the callee servlet is visible to the calling servlet when the servlets are in seperate web applications. Not only is this not compliant with the specification, but it's also a security issue. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH][jakarta-servletapi-5/jsr152] Documentation Patch
Update to clarify return values of TagVariableInfo.
- getClassName() will return java.lang.String if
the variable-class element is not specified.
- getDeclare() will return true if the declare
element is not specified.
- getScope() will return NESTED as the scope if
scope is not specified.
Index: TagVariableInfo.java
===
RCS file: /home/cvs/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/TagVariableInfo.java,v
retrieving revision 1.2
diff -u -r1.2 TagVariableInfo.java
--- TagVariableInfo.java 19 Aug 2002 16:29:51 - 1.2
+++ TagVariableInfo.java 10 Oct 2002 01:02:08 -
@@ -139,7 +139,8 @@
/**
* The body of the lt;variable-classgt; element.
*
- * @return The name of the class of the variable
+ * @return The name of the class of the variable or
+ * 'java.lang.String' if not defined in the TLD.
*/
public String getClassName() {
@@ -149,7 +150,8 @@
/**
* The body of the lt;declaregt; element
*
- * @return Whether the variable is to be declared or not
+ * @return Whether the variable is to be declared or not.
+ * If not defined in the TLD, 'true' will be returned.
*/
public boolean getDeclare() {
@@ -159,7 +161,9 @@
/**
* The body of the lt;scopegt; element
*
- * @return The scope to give the variable.
+ * @return The scope to give the variable. NESTED
+ * scope will be returned if not defined in
+ * the TLD.
*/
public int getScope() {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Cannot build mod_webapp.so on Solaris 8
I know this is not the proper place to ask configuration questions, but I do not believe this is such. I downloaded jakarta-tomcat-connectors-4.1.12-src.tar.gz from jakarta, and have read all the instructions. When I go to the webapp directory, README.txt says: How to build the WebApp module from CVS sources: -- -- If you downloaded the CVS sources (as described above) or downloaded a source distribution of the WebApp module, now all you need to do is build the binary module for your platform. To do so, start by doing a: ./configure --with-apxs make There is no configure script in webapps, nor can I find one anywhere else. The contents of the webapp directory are: total 81 -rw-r--r-- 1 mcmasjc sim 277 Sep 23 03:24 CHANGES -rw-r--r-- 1 mcmasjc sim 5663 Sep 23 03:24 INSTALL.txt -rw-r--r-- 1 mcmasjc sim 4436 Sep 23 03:24 LICENSE.txt -rw-r--r-- 1 mcmasjc sim 5809 Sep 23 03:24 Makedefs.in -rw-r--r-- 1 mcmasjc sim 9116 Sep 23 03:24 Makefile.in -rw-r--r-- 1 mcmasjc sim 6169 Sep 23 03:24 Makefile.win -rw-r--r-- 1 mcmasjc sim 5638 Sep 23 03:24 README.txt drwxr-xr-x 2 mcmasjc sim 512 Oct 9 16:48 apache-1.3 drwxr-xr-x 2 mcmasjc sim 512 Oct 9 16:48 apache-2.0 drwxr-xr-x 3 mcmasjc sim 512 Oct 10 10:14 build -rw-r--r-- 1 mcmasjc sim 4888 Sep 23 03:24 build.properties.in -rw-r--r-- 1 mcmasjc sim 7852 Sep 23 03:24 build.xml -rw-r--r-- 1 mcmasjc sim 19665 Sep 23 03:24 configure.in drwxr-xr-x 3 mcmasjc sim 512 Oct 9 16:48 docs drwxr-xr-x 2 mcmasjc sim 512 Oct 9 16:48 include drwxr-xr-x 3 mcmasjc sim 512 Sep 23 03:24 java drwxr-xr-x 2 mcmasjc sim 512 Oct 9 16:48 lib drwxr-xr-x 2 mcmasjc sim 512 Oct 9 16:48 support I looked in cvs, and there does not seem to be a configure script there either. Since there does not seem to be a binary for Solaris 8, I really need to build one. Can anyone tell me how to do that, or where to find configure? Thank you -- Jim McMaster mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: apps conversion from 3.3.1 to 4.1.12
From: news [mailto:[EMAIL PROTECTED]]On Behalf Of Costin Manolache Sent: Thursday, October 10, 2002 10:26 PM against access to resources is to use a sandbox. If you don't - ok, i understand, thanks.. Saludos, Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
jon 2002/10/10 15:04:24
Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
Log:
minor nit:
if close() throws an exception, then the index entry will never
get set to null.
-jon
Revision ChangesPath
1.47 +5 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
Index: WebappClassLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -r1.46 -r1.47
--- WebappClassLoader.java28 Aug 2002 10:05:05 - 1.46
+++ WebappClassLoader.java10 Oct 2002 22:04:24 - 1.47
@@ -1552,10 +1552,10 @@
for (int i = 0; i length; i++) {
try {
jarFiles[i].close();
-jarFiles[i] = null;
} catch (IOException e) {
// Ignore
}
+jarFiles[i] = null;
}
notFoundResources.clear();
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Constants.java Http11Processor.java InternalOutputBuffer.java
on 2002/10/10 6:14 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
+}
+
+
+/**
+ * Specialized utility method: find a sequence of lower case bytes inside
+ * a ByteChunk.
+ */
+protected int findBytes(ByteChunk bc, byte[] b) {
+
+byte first = b[0];
+byte[] buff = bc.getBuffer();
+int start = bc.getStart();
+int end = bc.getEnd();
+
+// Look for first char
+int srcEnd = b.length;
+
+for (int i = start; i = (end - srcEnd); i++) {
+if (buff[i] != first) continue;
+// found first char, now look for a match
+int myPos = i+1;
+for (int srcPos = 1; srcPos srcEnd; ) {
+if (buff[myPos++] != Ascii.toLower(b[srcPos++]))
+break;
+if (srcPos == srcEnd) return i - start; // found it
+}
+}
+return -1;
+
Tabs.
-jon
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13519] New: - tomcat4.1.12 failed to deploy context not under webapp directory with 'allowLinking' enabled
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13519. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13519 tomcat4.1.12 failed to deploy context not under webapp directory with 'allowLinking' enabled Summary: tomcat4.1.12 failed to deploy context not under webapp directory with 'allowLinking' enabled Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Please see user msg below http://www.mail-archive.com/tomcat-user%40jakarta.apache.org/msg69367.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH][jakarta-servletapi-5/jsr152] Resubmit of documentation path.
Please use the attached patch instead of the one I previously posted.
Changes
TagVariableInfo
- getClassName() will return java.lang.String if
the variable-class element is not specified.
- getDeclare() will return true if the declare
element is not specified.
- getScope() will return NESTED as the scope if
scope is not specified.
TagLibraryInfo
- Changed the directive from include to taglib in
description of getShortName().
- Minor rewording of getReliableURN for clarity.
Thanks,
-rl
Index: TagLibraryInfo.java
===
RCS file: /home/cvs/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/TagLibraryInfo.java,v
retrieving revision 1.3
diff -u -r1.3 TagLibraryInfo.java
--- TagLibraryInfo.java 20 Aug 2002 21:08:24 - 1.3
+++ TagLibraryInfo.java 10 Oct 2002 23:38:29 -
@@ -148,7 +148,7 @@
/**
* The preferred short name (prefix) as indicated in the TLD.
* This may be used by authoring tools as the preferred prefix
- * to use when creating an include directive for this library.
+ * to use when creating an taglib directive for this library.
*
* @return the preferred short name for the library
*/
@@ -157,10 +157,9 @@
}
/**
- * The reliable URN indicated in the TLD.
+ * The reliable URN indicated in the TLD (the uri element).
* This may be used by authoring tools as a global identifier
- * (the uri attribute) to use when creating a taglib directive
- * for this library.
+ * to use when creating a taglib directive for this library.
*
* @return a reliable URN to a TLD like this
*/
Index: TagVariableInfo.java
===
RCS file: /home/cvs/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/TagVariableInfo.java,v
retrieving revision 1.2
diff -u -r1.2 TagVariableInfo.java
--- TagVariableInfo.java 19 Aug 2002 16:29:51 - 1.2
+++ TagVariableInfo.java 10 Oct 2002 23:38:30 -
@@ -139,7 +139,8 @@
/**
* The body of the lt;variable-classgt; element.
*
- * @return The name of the class of the variable
+ * @return The name of the class of the variable or
+ * 'java.lang.String' if not defined in the TLD.
*/
public String getClassName() {
@@ -149,7 +150,8 @@
/**
* The body of the lt;declaregt; element
*
- * @return Whether the variable is to be declared or not
+ * @return Whether the variable is to be declared or not.
+ * If not defined in the TLD, 'true' will be returned.
*/
public boolean getDeclare() {
@@ -159,7 +161,9 @@
/**
* The body of the lt;scopegt; element
*
- * @return The scope to give the variable.
+ * @return The scope to give the variable. NESTED
+ * scope will be returned if not defined in
+ * the TLD.
*/
public int getScope() {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13419] - Weird seg fault on Mac OS X for mod_jk2 + Apache2
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13419.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13419
Weird seg fault on Mac OS X for mod_jk2 + Apache2
--- Additional Comments From [EMAIL PROTECTED] 2002-10-11 00:42 ---
Costin,
I compiled with '-g' flag only. No optimization.
Before I put in the printf's, similar seg fault was at this line:
if(0 == strcmp(mPriv-names[i], name)) {
I know it's weird since I check for NULL a few lines above it.
This kind of error is almost like mem was deallocated accidentally,
before it is used.
I saw on the mailing list that someone else has a similar seg fault on
Solaris as well.
Thanks!
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jk2 and daemon ( was Re: commons-daemon release ?)
On 10/10/02 20:21, Costin Manolache [EMAIL PROTECTED] wrote: The 'feature' is that all tomcat processes ( and you may run more than one in a load balanced mode ) can be started automatically and monitored. If one dies, it'll be automatically restarted. tip http://cr.yp.to/daemontools.html It's there, it works, don't reinvent the wheel /tip To make things interesting, this information ( and other like that ) needs to be communicated to apache servers ( to stop sending requests to not-ready servers ), and potentially to an eventual JMX proxy. This is the kind of 'control channel' that was proposed several times and will have to be implemented for other purposes. I read Covalent Managed Servers Console all over the place on this one! :-) Incredible what marketing does to people! :-) I also know that maybe a couple of clients of yours here in London might like that feature, as they asked me if it was possible to implement... :-) As far as I'm concerned, I'm happy with my old way of CVSing out web-applications and deploying them on my servers keeping them in sync, and if something dies, Mr. Bergstein (cr.yp.to) already wrote everything I need! :-) So there are separate issues - the most important beeing the startup of tocmat(s) automatically ( like jserv - but not strictly tied to apache process lifecycle ). I can tell you that our main Java instance for VNUNET.COM takes approximately 4 to 5 minutes to start... If I don't reply to HTTP when that thing is down, I'm going to loose my job, so it's not something I feel that in a real-life production environment comes handy... That said, if that's your itch, scratch it... I'm not going to use it! :-) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Cannot build mod_webapp.so on Solaris 8
On 10/10/02 22:23, James C. McMaster (Jim) [EMAIL PROTECTED] wrote: I know this is not the proper place to ask configuration questions, but I do not believe this is such. Use mod_jk -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
ProxyName problem
Hey all, For Scarab (using Tomcat 4.0.6), I want to be able to do something like this (server.xml): Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=@TOMCAT_HTTP_PORT@ minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=6 proxyName=@TOMCAT_PROXY_NAME@ proxyPort=@TOMCAT_PROXY_PORT@/ Where Ant would then replace proxyName/proxyPort with a value *IF DEFINED*. If it isn't defined, then it would replace it with . Now, this *almost* works in that if proxyPort=, then the default port is used. BUT, if proxyName=, then request.getServerName() returns , which is clearly bad. Instead, if it is , I would rather have it return the default that the Host: header is set to (or worst case, use InetAddress.getLocalHost().getHostName();). Comments? -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jk2 and daemon ( was Re: commons-daemon release ?)
on 2002/10/10 6:50 PM, Pier Fumagalli [EMAIL PROTECTED] wrote: I can tell you that our main Java instance for VNUNET.COM takes approximately 4 to 5 minutes to start... OUCH. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jk2 and daemon ( was Re: commons-daemon release ?)
On 11/10/02 3:14, Jon Scott Stevens [EMAIL PROTECTED] wrote: on 2002/10/10 6:50 PM, Pier Fumagalli [EMAIL PROTECTED] wrote: I can tell you that our main Java instance for VNUNET.COM takes approximately 4 to 5 minutes to start... OUCH. Our main web-app has roughly 400 JSP pages to compile (you never know), 20 servlets loaded on startup, 4 lucene indexes to open, 500 connections to the database, 350/400 megabytes of cached objects to de-serialize and put down into memory, and some initial synchronization checks with the DB to find out what are the articles that need to be displayed first (articles ranking) out of an history of some hundred thousand of them (all on line)... It is a big bubba, the JVM memory size is somewhat in the range of 640 Mb... :-) (and it's just 1 web-application out of 6) Only problem? Tomcat doesn't scale that high :-( Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 CoyoteConnector.java
billbarker2002/10/10 19:33:08
Modified:coyote/src/java/org/apache/coyote/tomcat4
CoyoteConnector.java
Log:
Add at least minimal sanity checking on the 'proxyName' value.
Now proxyName= is the same as omitting it all together.
Reported by: Jon Scott Stevens [EMAIL PROTECTED]
Revision ChangesPath
1.16 +9 -5
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteConnector.java
Index: CoyoteConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteConnector.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- CoyoteConnector.java 28 May 2002 14:24:31 - 1.15
+++ CoyoteConnector.java 11 Oct 2002 02:33:07 - 1.16
@@ -667,7 +667,11 @@
*/
public void setProxyName(String proxyName) {
-this.proxyName = proxyName;
+if(! .equals(proxyName) {
+this.proxyName = proxyName;
+} else {
+this.proxyName = null;
+}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 CoyoteConnector.java
billbarker2002/10/10 19:38:23
Modified:coyote/src/java/org/apache/coyote/tomcat4
CoyoteConnector.java
Log:
Write 100 times: Compile, then commit.
Revision ChangesPath
1.17 +5 -5
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteConnector.java
Index: CoyoteConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteConnector.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- CoyoteConnector.java 11 Oct 2002 02:33:07 - 1.16
+++ CoyoteConnector.java 11 Oct 2002 02:38:22 - 1.17
@@ -667,7 +667,7 @@
*/
public void setProxyName(String proxyName) {
-if(! .equals(proxyName) {
+if(! .equals(proxyName) ) {
this.proxyName = proxyName;
} else {
this.proxyName = null;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13523] New: - problem using JSTL fmt:setLocale with Tomcat 4.1.9
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13523.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13523
problem using JSTL fmt:setLocale with Tomcat 4.1.9
Summary: problem using JSTL fmt:setLocale with Tomcat 4.1.9
Product: Tomcat 4
Version: 4.1.9
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Critical
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
To demonstrate the problem first create two resource bundle properties files
as follows:
--
labels_en.properties:
hello=hello
goodbye=goodbye
--
labels_es.properties:
hello=hola
goodbye=adios
--
put them in a jar and place the jar in the WEB-INF/lib dir of a webapp
now place the following code into a .jsp file and put it in the main dir of
the same webapp where you put the resource bundle jar
--
%-- possible tomcat bug when using JSTL fmt:setLocale
--%
%@ taglib prefix=c uri=http://java.sun.com/jstl/core; %
%@ taglib prefix=fmt uri=http://java.sun.com/jstl/fmt; %
html
body
c:if test=${param.locale != null}
fmt:setLocale value=${param.locale} scope=session /
/c:if
a href=?locale=enEnglish/a -
a href=?locale=esSpanish/a -
br /br /
jsp:useBean id=now class=java.util.Date /
The date functions seem to work correctly with regard to locale.br /
Date: fmt:formatDate value=${now} dateStyle=full /br /
Time: fmt:formatDate value=${now} type=time /br /
br /
%-- create a jar with the resource bundles .class and/or .properties files
that contain the key=value pairs:
e.g.: labels_en.properties, labels_es.properties
and place it in the WEB-INF/lib dir of your webapp
--%
fmt:setBundle basename=labels var=labelsBundle scope=session/
fmt:bundle basename=labels
The bundle functions do not seem to work correctly with regard to localebr /
unless we specifically do a lt;fmt:setLocale
value=hard_coded_string /gt;.br /
It seems as though the fmt:setLocale is interpreted at compile time not
runtime.br /
Hello: fmt:message key=hello /br /
Goodbye: fmt:message key=goodbye /
/fmt:bundle
/body
/html
--
bring up browser and access the .jsp file
http://localhost:8080/thewebapp/thefile.jsp
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13419] - Weird seg fault on Mac OS X for mod_jk2 + Apache2
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13419 Weird seg fault on Mac OS X for mod_jk2 + Apache2 --- Additional Comments From [EMAIL PROTECTED] 2002-10-11 04:17 --- Ok, I don't really know enough about what's going on, (I'm mostly just a lurker) however... An of the wall guess would be that the passed string has no null terminator. This would cause strlen() to seg fault once it had run over the end of its memory space. If the address itself is bad, you can test by just outputting the first few characters. If that doesn't dump core then it's most likely a null termination problem. Not that it helps. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jk2 and daemon ( was Re: commons-daemon release ?)
Quoting Pier Fumagalli [EMAIL PROTECTED]: Our main web-app has roughly 400 JSP pages to compile (you never know), 20 servlets loaded on startup, 4 lucene indexes to open, 500 connections to the database, 350/400 megabytes of cached objects to de-serialize and put down into memory, and some initial synchronization checks with the DB to find out what are the articles that need to be displayed first (articles ranking) out of an history of some hundred thousand of them (all on line)... It is a big bubba, the JVM memory size is somewhat in the range of 640 Mb... :-) (and it's just 1 web-application out of 6) Only problem? Tomcat doesn't scale that high :-( Since you like segfaults better then NPE's and you seem to need performance, maybe you should try CSP's: http://astro.temple.edu/~john43/ ;-) Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 CoyoteConnector.java
[EMAIL PROTECTED] wrote: billbarker2002/10/10 19:38:23 Modified:coyote/src/java/org/apache/coyote/tomcat4 CoyoteConnector.java Log: Write 100 times: Compile, then commit. So I'm not the only one ! :-) -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit:jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4CoyoteConnector.java
on 2002/10/10 7:33 PM, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
+if(! .equals(proxyName)) {
I usually do:
if (proxyName != null proxyName.length() 0)
Looking at the source code to String.java, that is a far more efficient way
to do things (would be nice if that code was at the top of String.equals(),
but it isn't). You can probably take out the null check, if you know the
string won't be null, but that is only a minor optimization.
-jon
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4CoyoteConnector.java
On Thu, 10 Oct 2002, Costin Manolache wrote: Date: Thu, 10 Oct 2002 21:29:51 -0700 From: Costin Manolache [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 CoyoteConnector.java [EMAIL PROTECTED] wrote: billbarker2002/10/10 19:38:23 Modified:coyote/src/java/org/apache/coyote/tomcat4 CoyoteConnector.java Log: Write 100 times: Compile, then commit. So I'm not the only one ! :-) Nah ... we've *all* done that one more times than we care to admit :-). -- Costin Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13516] - Servlet Specification Incompatibility - Sessions are not correctly scoped according to the Servlet Specification
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13516. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13516 Servlet Specification Incompatibility - Sessions are not correctly scoped according to the Servlet Specification [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-10-11 05:29 --- *** This bug has been marked as a duplicate of 4690 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4690] - sessions not scoped according to spec section 7.3
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4690. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4690 sessions not scoped according to spec section 7.3 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-10-11 05:29 --- *** Bug 13516 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
