Re: Jk2 object model
I'm pretty busy these days so I can't works on JK2 as I want to. Some ideas/reflexions. JK2 is very similar to JK, from the tomcat point of vue, since the same ajp13 protocol is used, and may be in such case we could see JK2 too similar to JK to see users switch to JK2 (for instance we're still using JK in-house). In thread I read some says that JK2 is allready dead, and in such case, using JK2 to make what JK does, it may be true. I'm working on an in-house project were I'm using jchannels to make some applications works with cluster of service servers and that's an idea which could be fine for JK2, or JK2++ or JK3. Using this kind of high-level communication channels help make automatic clusters, without the need on the client (on our case Apache/IIS) to know the topology. I didn't know if a native (C/C++) jchannel implementation exist but if we could find one, I think we should think to use it to make JK2 more that just JK++. The benefits are enormous, automatic detection of tomcats when added or removed from the group, determination of webapp/url which could be handled What about ? Oups, you should read javagroups (http://www.jgroups.org) in place of jchannels ;) JGroups is really a great piece of code but miss native code implementation. But the idea is here, and if we could find the same kind of code with native and java implementation, we should take a look at it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25977] New: - commons-dbcp-1.1.jar not working properly with Oracle JDBC +XSU
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=25977. 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=25977 commons-dbcp-1.1.jar not working properly with Oracle JDBC +XSU Summary: commons-dbcp-1.1.jar not working properly with Oracle JDBC +XSU Product: Tomcat 5 Version: 5.0.16 Platform: PC OS/Version: Windows XP Status: NEW Severity: Enhancement Priority: Other Component: Catalina:Modules AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Oracle XSU (xml-sql-utility) working with oracle JDBC driver and it's require connection to be instance of oracle.jdbc.driver.OracleConnection but tomcat pool return org.apache.commons.dbcp.PoolableConnection and XSU crash... plz make any method or any possibility to get physical connection from pool.. (the real oracle connection) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25977] - Commons DBCP not working properly with Oracle JDBC +XSU
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=25977. 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=25977 Commons DBCP not working properly with Oracle JDBC +XSU [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID Summary|commons-dbcp-1.1.jar not |Commons DBCP not working |working properly with Oracle|properly with Oracle JDBC |JDBC +XSU |+XSU --- Additional Comments From [EMAIL PROTECTED] 2004-01-08 10:01 --- Please post on tomcat-user. You have ways to do this (such as writing your own JNDI object factory). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans MBeanFactory.java
[EMAIL PROTECTED] wrote: amyroh 2004/01/07 21:32:25 Modified:catalina/src/share/org/apache/catalina/core StandardHost.java catalina/src/share/org/apache/catalina/mbeans MBeanFactory.java Log: Fix bugzilla 25878 - Add HostConfig after new Host is created via admin and prevent duplicate errorReportValve creation after restart. Patch submitted by [EMAIL PROTECTED] (Peter Rossbach). I thought the StandardHost patch wasn't super clean. I think keeping a reference to the valve (and removing it on stop using that) would likely be a lot better. I'll see if I can improve it. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25878] - Host created with Admin Application only ready, after complete tomcat restart
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=25878. 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=25878 Host created with Admin Application only ready, after complete tomcat restart [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-08 10:35 --- Your patch has been committed. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25948] - FIX: Manager App can't redeploy ROOT applications
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25948. 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=25948 FIX: Manager App can't redeploy ROOT applications --- Additional Comments From [EMAIL PROTECTED] 2004-01-08 10:40 --- I found two more wrong undeploy parameter at ManagerServlet. But following situation was strange: Context Deployment with a context path=/ work also, but you can't undeploy those ROOT Context. The spezial ROOT context path handling with out / not working at the ContextRuleSet configured context. The result is the manager application can't find the ROOT application. ManagerServlet unddeploy(..) -... deployer.findDeployedApp() # search for but the ROOT context is registerted under /. OK: The doc say set path to is the only way two set ROOT context but the ManagerServlet can load a context.xml with path / as ROOT context! Strange... Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25948] - FIX: Manager App can't redeploy ROOT applications
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25948. 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=25948 FIX: Manager App can't redeploy ROOT applications --- Additional Comments From [EMAIL PROTECTED] 2004-01-08 10:42 --- Created an attachment (id=9855) ManagerServlet patch with correct undeploy parameter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25948] - FIX: Manager App can't redeploy ROOT applications
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25948. 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=25948 FIX: Manager App can't redeploy ROOT applications --- Additional Comments From [EMAIL PROTECTED] 2004-01-08 10:44 --- Yes, context path = / is bad, and won't work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java
remm2004/01/08 03:11:33
Modified:util/java/org/apache/tomcat/util/http/mapper Mapper.java
Log:
- Cosmetic changes.
- Remove useless check for null.
- Use static on the inner classes.
Revision ChangesPath
1.33 +6 -8
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper/Mapper.java
Index: Mapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper/Mapper.java,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- Mapper.java 23 Dec 2003 11:09:50 - 1.32
+++ Mapper.java 8 Jan 2004 11:11:33 - 1.33
@@ -519,9 +519,7 @@
MappingData mappingData)
throws Exception {
-if (host != null) {
-host.toChars();
-}
+host.toChars();
uri.toChars();
internalMap(host.getCharChunk(), uri.getCharChunk(), mappingData);
@@ -1113,7 +,7 @@
// - MapElement Inner Class
-protected abstract class MapElement {
+protected static abstract class MapElement {
public String name = null;
public Object object = null;
@@ -1124,7 +1122,7 @@
// --- Host Inner Class
-protected final class Host
+protected static final class Host
extends MapElement {
public ContextList contextList = null;
@@ -1135,7 +1133,7 @@
// ContextList Inner Class
-protected final class ContextList {
+protected static final class ContextList {
public Context[] contexts = new Context[0];
public int nesting = 0;
@@ -1146,7 +1144,7 @@
// Context Inner Class
-protected final class Context
+protected static final class Context
extends MapElement {
public String path = null;
@@ -1164,7 +1162,7 @@
// Wrapper Inner Class
-protected class Wrapper
+protected static class Wrapper
extends MapElement {
public String path = null;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25127] - Tomcat 4.1.29 will not start with IBM JDK 1.3.0
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=25127. 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=25127 Tomcat 4.1.29 will not start with IBM JDK 1.3.0 --- Additional Comments From [EMAIL PROTECTED] 2004-01-08 11:03 --- I have the same problem on Win2000, Sun-JDK 1.3.0c. After same research I found out that the problem are index.list files which were added to some JARs in the 4.1.29 build. These files should speed up the classloader (see http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html). But somehow they don't work in this case. For testing create a small app which has tomcat-coyote.jar in it's classpath, and import the org.apache.coyote.*-namespace. Then make the following call: ResourceBundle rb = ResourceBundle.getBundle (org.apache.coyote.tomcat4.LocalStrings); You will get the same exception you get with tomcat. Workaround: Remove the index.list files from ALL the tomcat jars. There are some (beetween 5 and 10 I think). The easiest way (with windows) is to search for the string index.list in all JAR-Files in the tomcat directory. Then open each with winzip and delete the index.list file. After this tomcat is starting once again. The only difference should be that classloading is as fast/slow as in 4.1.27. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager ManagerServlet.java
remm2004/01/08 03:09:03
Modified:webapps/manager/WEB-INF/classes/org/apache/catalina/manager
ManagerServlet.java
Log:
- Undeploy should be called with the displayed path to be able to work on
the root context.
- Bug 25948.
- Submitted by Peter Rossbach.
Revision ChangesPath
1.14 +8 -8
jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/ManagerServlet.java
Index: ManagerServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/ManagerServlet.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- ManagerServlet.java 29 Nov 2003 08:33:48 - 1.13
+++ ManagerServlet.java 8 Jan 2004 11:09:03 - 1.14
@@ -617,7 +617,7 @@
Context context = deployer.findDeployedApp(path);
if (update) {
if (context != null) {
-undeploy(writer, path);
+undeploy(writer, displayPath);
}
context = deployer.findDeployedApp(path);
}
@@ -735,7 +735,7 @@
// Check if app already exists, or undeploy it if updating
Context context = deployer.findDeployedApp(path);
if (context != null) {
-undeploy(writer, path);
+undeploy(writer, displayPath);
}
// Copy WAR and XML to the host base
@@ -912,7 +912,7 @@
Context context = deployer.findDeployedApp(path);
if (update) {
if (context != null) {
-undeploy(writer, path);
+undeploy(writer, displayPath);
}
context = deployer.findDeployedApp(path);
}
@@ -1599,7 +1599,7 @@
* specified file location.
*
* @param request The servlet request we are processing
- * @param file The file into which we should store the uploaded WAR
+ * @param war The file into which we should store the uploaded WAR
*
* @exception IOException if an I/O error occurs during processing
*/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25948] - FIX: Manager App can't redeploy ROOT applications
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25948. 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=25948 FIX: Manager App can't redeploy ROOT applications [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-08 11:09 --- Fixed. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jk2 object model
Hi, Since I've started few months ago all the C++ fuzziness (I did posted even some source to Costin back then), my intention wasn't to CPP-ize the existing code, but rather to move that 'dead' code on some new tracks. What I'm looking since then is some kind of different approach to the subject. I'll take a good look at javagroups. Seems to me that this is something that I had in my mind for a while, meaning leaving all the communication and configuration to some Java proxy, and having native only to communicate with that proxy. What I was looking at was the way to find the 'more intelligent' way of integration, definitely having GUI (html) configuration, something like TC Manager, and cacheable configuration on the native side (today's jvm's are IMO quite different with native integration then 1.2 was back in days when JK2 was started). The native part would have to be as simple as possible, having only the jvm and classloader, and few native calls, allowing it to be integrated not only in Web server, but with the simple console client too. I agree with you that this would be JK3, rather then JK2 on steroids :-), and it would require a different perspective. I'm in favor of _usability_ over performance in that new approach. The major question is are there any developer interest on that? Also I wouldn't like to been seen as 'a JK2 killer', but if we are frankly with ourselves, there wasn't a major JK2 technological advantage for more then a year, and there isn't much interest of the developer community thought. I also use the JK for production servers, and it is doing just fine for what it needs to. MT. -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED] Sent: 8. sijeanj 2004 9:54 To: Tomcat Developers List Subject: Re: Jk2 object model I'm pretty busy these days so I can't works on JK2 as I want to. Some ideas/reflexions. JK2 is very similar to JK, from the tomcat point of vue, since the same ajp13 protocol is used, and may be in such case we could see JK2 too similar to JK to see users switch to JK2 (for instance we're still using JK in-house). In thread I read some says that JK2 is allready dead, and in such case, using JK2 to make what JK does, it may be true. I'm working on an in-house project were I'm using jchannels to make some applications works with cluster of service servers and that's an idea which could be fine for JK2, or JK2++ or JK3. Using this kind of high-level communication channels help make automatic clusters, without the need on the client (on our case Apache/IIS) to know the topology. I didn't know if a native (C/C++) jchannel implementation exist but if we could find one, I think we should think to use it to make JK2 more that just JK++. The benefits are enormous, automatic detection of tomcats when added or removed from the group, determination of webapp/url which could be handled What about ? Oups, you should read javagroups (http://www.jgroups.org) in place of jchannels ;) JGroups is really a great piece of code but miss native code implementation. But the idea is here, and if we could find the same kind of code with native and java implementation, we should take a look at it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jk2 object model
Mladen Turk a crit : Hi, Since I've started few months ago all the C++ fuzziness (I did posted even some source to Costin back then), my intention wasn't to CPP-ize the existing code, but rather to move that 'dead' code on some new tracks. What I'm looking since then is some kind of different approach to the subject. I'll take a good look at javagroups. Seems to me that this is something that I had in my mind for a while, meaning leaving all the communication and configuration to some Java proxy, and having native only to communicate with that proxy. What I was looking at was the way to find the 'more intelligent' way of integration, definitely having GUI (html) configuration, something like TC Manager, and cacheable configuration on the native side (today's jvm's are IMO quite different with native integration then 1.2 was back in days when JK2 was started). The native part would have to be as simple as possible, having only the jvm and classloader, and few native calls, allowing it to be integrated not only in Web server, but with the simple console client too. I agree with you that this would be JK3, rather then JK2 on steroids :-), and it would require a different perspective. I'm in favor of _usability_ over performance in that new approach. The major question is are there any developer interest on that? Also I wouldn't like to been seen as 'a JK2 killer', but if we are frankly with ourselves, there wasn't a major JK2 technological advantage for more then a year, and there isn't much interest of the developer community thought. I also use the JK for production servers, and it is doing just fine for what it needs to. JavaGroups or other reliable multicast implemtations is great for the web server since it will discover the tomcats topology. For speed I need more experience, or comments from Filip Hanick, we should be subscribed on this list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jk2 object model
-Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED] I agree with you that this would be JK3, rather then JK2 on steroids :-), and it would require a different perspective. I'm in favor of _usability_ over performance in that new approach. JavaGroups or other reliable multicast implemtations is great for the web server since it will discover the tomcats topology. I didn't said that the javagroups is what I need, only that it has the concept I was perusing for. For speed I need more experience, or comments from Filip Hanick, we should be subscribed on this list. As I said, the performance isn't a priority here, but rather usability. I'm sure that TC guys will be open here, and we will see (perhaps even in 5.1) the 'open TC API', that could be directly used, or seamlessly integrated from the native side. I would prefer to see that, rather then trying to 'discover' something, and after all it would 'stay in the house', since I wish to make a connector(integrator) for Tomcat, not for some xyz container. Of course this would imply the firm collaboration with the TC guys, but once again I don't wish to pack/unpack something over and over again (I have JK for that). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25980] New: - Documentation relating to where jsp examples are needs update
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=25980. 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=25980 Documentation relating to where jsp examples are needs update Summary: Documentation relating to where jsp examples are needs update Product: Tomcat 5 Version: 5.0.16 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Webapps:Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The documentation needs to be updated to point to http://localhost:8080/jsp-examples/security/protected/ Instead of the current http://localhost:8080/examples/jsp/security/protected/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25981] New: - jsp security example does not work!
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25981. 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=25981 jsp security example does not work! Summary: jsp security example does not work! Product: Tomcat 5 Version: 5.0.16 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Webapps:Examples AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Default install from a binary to /usr/local/jakarta-tomcat-5.0.16 Access to http://localhost:8080/jsp-examples/security/protected/; causes redirection to login.jsp, as expected Access to http://localhost:8080/jsp-examples/security/protected/index.jsp; causes redirection to the login.jsp as expected. The login.jsp and error.jsp pages are displayed correctly It seems as if the user/password/realm are not being recognized. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25981] - jsp security example does not work!
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25981. 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=25981 jsp security example does not work! [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-01-08 12:36 --- It works for me now. Please do not reopen the report. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jk2 object model
Hate to quote myself, but... As I said, the performance isn't a priority here, but rather usability. I'm sure that TC guys will be open here, and we will see (perhaps even in 5.1) the 'open TC API', that could be directly used, or seamlessly integrated from the native side. I would prefer to see that, rather then trying to 'discover' something, and after all it would 'stay in the house', since I wish to make a connector(integrator) for Tomcat, not for some xyz container. Of course this would imply the firm collaboration with the TC guys, but once again I don't wish to pack/unpack something over and over again (I have JK for that). The concept (approach) as I see it is to be able to make a connector (integrator), that would allow the zero-based-configuration. Meaning that loading a module (filter) will automatically map the Tomcat web space to the web server. No matter if the TC was started in or out of the process, and no matter how much clustered instances exists on different nodes. If there is developer interest for that, I'm willing to 'shake the things'. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
remm2004/01/08 05:08:13
Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
Log:
- Report an exception which occurred during a low level flush.
Revision ChangesPath
1.93 +1 -0
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
Index: Http11Processor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
retrieving revision 1.92
retrieving revision 1.93
diff -u -r1.92 -r1.93
--- Http11Processor.java 2 Dec 2003 23:01:01 - 1.92
+++ Http11Processor.java 8 Jan 2004 13:08:13 - 1.93
@@ -946,6 +946,7 @@
} catch (IOException e) {
// Set error flag
error = true;
+response.setErrorException(e);
}
} else if (actionCode == ActionCode.ACTION_CLOSE) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 OutputBuffer.java
remm2004/01/08 05:09:04
Modified:catalina/src/share/org/apache/coyote/tomcat5
OutputBuffer.java
Log:
- Throw a wrapped IOE when an exception occurs during a low level flush.
Revision ChangesPath
1.7 +6 -0
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/OutputBuffer.java
Index: OutputBuffer.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/OutputBuffer.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- OutputBuffer.java 12 Sep 2003 13:16:41 - 1.6
+++ OutputBuffer.java 8 Jan 2004 13:09:04 - 1.7
@@ -368,6 +368,12 @@
if (realFlush) {
coyoteResponse.action(ActionCode.ACTION_CLIENT_FLUSH,
coyoteResponse);
+// If some exception occurred earlier, or if some IOE occurred
+// here, notify the servlet with an IOE
+if (coyoteResponse.isExceptionPresent()) {
+throw new ClientAbortException
+(coyoteResponse.getErrorException());
+}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 OutputBuffer.java
remm2004/01/08 05:09:39
Modified:coyote/src/java/org/apache/coyote/tomcat4 OutputBuffer.java
Log:
- Port patch to 4.1.x.
Revision ChangesPath
1.12 +6 -0
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/OutputBuffer.java
Index: OutputBuffer.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/OutputBuffer.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- OutputBuffer.java 18 Sep 2003 16:13:51 - 1.11
+++ OutputBuffer.java 8 Jan 2004 13:09:39 - 1.12
@@ -362,6 +362,12 @@
if (realFlush) {
coyoteResponse.action(ActionCode.ACTION_CLIENT_FLUSH,
coyoteResponse);
+// If some exception occurred earlier, or if some IOE occurred
+// here, notify the servlet with an IOE
+if (coyoteResponse.isExceptionPresent()) {
+throw new ClientAbortException
+(coyoteResponse.getErrorException());
+}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 4663] - Broken Pipe under some load
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=4663. 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=4663 Broken Pipe under some load [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-01-08 13:23 --- As stated before this is not a bug. This happens during normal operation of Tomcat when the web server side tears down the tomcat connector socket due to the remote client terminating its request prior to handling of the request by tomcat completing. Here is what happens: 1. Remote browser makes a request to web server. 2. Web server sends request to tomcat via the JK connector. 3. Tomcat starts processing request. 4. Tomcat's output buffer fills so it sends it back to the web server via the connector socket. 5. web server tries to write the buffer back to the remote client browser. 6. The web server write to the remote client browser fails because the user hit STOP in their browser to abandon the request. 7. web server process/thread detects this. To free up resources since the request was abandoned the web server process/thread closes the connector socket to Tomcat. Then it can recycle itself so it is available for another http request. 8. On the Tomcat side it will fail when it tries to write additional output to the connector socket. This triggers the exception you see. 9. Now Tomcat can terminate processing the abandoned request if it hadn't been completed yet. This is all perfectly normal. Please do not reopen this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25980] - Documentation relating to where jsp examples are needs update
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=25980. 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=25980 Documentation relating to where jsp examples are needs update [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-08 13:25 --- Thanks. That page isn't really up to date anyway, so many more updates are needed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadPool.java
remm2004/01/08 05:56:36
Modified:util/java/org/apache/tomcat/util/threads ThreadPool.java
Log:
- Some suggestions that were sent by Dave Dice. Jean François assured me
he did test this, so since this looks harmless to me (and won't hurt performance
either), I'm willing to try them. Actually, this looks to me that it won't do
anything,
but what do I know ;-)
Revision ChangesPath
1.20 +15 -9
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java
Index: ThreadPool.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- ThreadPool.java 25 Dec 2003 03:08:31 - 1.19
+++ ThreadPool.java 8 Jan 2004 13:56:36 - 1.20
@@ -644,17 +644,23 @@
}
public void run() {
+boolean _shouldRun = false;
+boolean _shouldTerminate = false;
+ThreadPoolRunnable _toRun = null;
try {
while(true) {
try {
/* Wait for work. */
synchronized(this) {
-if(!shouldRun !shouldTerminate) {
+while (!shouldRun !shouldTerminate) {
this.wait();
}
+_shouldRun = shouldRun;
+_shouldTerminate = shouldTerminate;
+_toRun = toRun;
}
-if( shouldTerminate ) {
+if( _shouldTerminate ) {
if( p.log.isDebugEnabled())
p.log.debug( Terminate);
break;
@@ -663,8 +669,8 @@
/* Check if should execute a runnable. */
try {
if(noThData) {
-if( toRun != null ) {
-Object thData[]=toRun.getInitData();
+if( _toRun != null ) {
+Object thData[]=_toRun.getInitData();
t.setThreadData(p, thData);
if(p.log.isDebugEnabled())
p.log.debug( Getting new thread data);
@@ -672,9 +678,9 @@
noThData = false;
}
-if(shouldRun) {
- if( toRun != null ) {
-toRun.runIt(t.getThreadData(p));
+if(_shouldRun) {
+ if( _toRun != null ) {
+_toRun.runIt(t.getThreadData(p));
} else if( toRunRunnable != null ) {
toRunRunnable.run();
} else {
@@ -696,7 +702,7 @@
shouldRun = false;
p.notifyThreadEnd(this);
} finally {
-if(shouldRun) {
+if(_shouldRun) {
shouldRun = false;
/*
* Notify the pool that the thread is now idle.
@@ -709,7 +715,7 @@
* Check if should terminate.
* termination happens when the pool is shutting down.
*/
-if(shouldTerminate) {
+if(_shouldTerminate) {
break;
}
} catch(InterruptedException ie) { /* for the wait operation */
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
please help me sir
respected sir, I have a problem in configuration of TOMCAT4.1.29 ... I am working on win98 jdk1.3.1_09 there is a problem while run JSP file .. syntax error message is desplay when I run startup.bat file so, please give your suggession ronak - Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes
RE: please help me sir
From: Ronak Patel respected sir, I have a problem in configuration of TOMCAT4.1.29 ... I am working on win98 jdk1.3.1_09 First of all I would suggest that you move to some NT-based platform, but only after resolving the cause of a problem. there is a problem while run JSP file .. syntax error message is desplay when I run startup.bat file so, please give your suggession ronak I would suggest that you put your question to the tomcat-users list, with more detailed explanation of your problem. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ServletRequest.setCharacterEncoding() and GET parameters
Hi, I have found recently that current TomCat 5 uses different encoding for POST and GET parameters. I was quite surprised, because all bugs opened for this issue are just closed as invalid without an explanation. But after a long searching I found the discussion about bug 23929 at http://www.mail-archive.com/[EMAIL PROTECTED]/msg50866.html and I understand now that in the next realease, there will be a configuration option useBodyEncodingForURI=true of a connector. I just want to say that I think that it should be the default setting, not something that must be found after searching web and mail archives for several hours and manually injected into server.xml I agree with Jess Hole that it is a de facto standard and the SUN servlet specification seems to indicate that setCharacterEncoding() should affect all parameters. Remember that GET and POST parameters are merged together. Using different encoding for GET and POST parameters by default is counter-intuitive and breaks the Principle of least astonishment. If it is kept that way, the same bug will be reported again and again. Martin -- ~~ Supercomputing Center Brno Martin Kuba Institute of Computer Scienceemail: [EMAIL PROTECTED] Masaryk University http://www.ics.muni.cz/~makub/ Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775 -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ServletRequest.setCharacterEncoding() and GET parameters
Martin Kuba wrote: Hi, I have found recently that current TomCat 5 uses different encoding for POST and GET parameters. I was quite surprised, because all bugs opened for this issue are just closed as invalid without an explanation. But after a long searching I found the discussion about bug 23929 at http://www.mail-archive.com/[EMAIL PROTECTED]/msg50866.html and I understand now that in the next realease, there will be a configuration option useBodyEncodingForURI=true of a connector. I just want to say that I think that it should be the default setting, not something that must be found after searching web and mail archives for several hours and manually injected into server.xml I agree with Jess Hole that it is a de facto standard and the SUN servlet specification seems to indicate that setCharacterEncoding() should affect all parameters. Remember that GET and POST parameters are merged together. Using different encoding for GET and POST parameters by default is counter-intuitive and breaks the Principle of least astonishment. If it is kept that way, the same bug will be reported again and again. -1. The attribute, now that it actually exists, is well documented. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs proxy-howto.xml
remm2004/01/08 06:55:57 Modified:webapps/docs proxy-howto.xml Log: - No className is needed anymore. Revision ChangesPath 1.6 +3 -4 jakarta-tomcat-catalina/webapps/docs/proxy-howto.xml Index: proxy-howto.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/proxy-howto.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- proxy-howto.xml 26 Nov 2003 03:43:31 - 1.5 +++ proxy-howto.xml 8 Jan 2004 14:55:57 - 1.6 @@ -76,10 +76,9 @@ codelt;Connectorgt;/code element, with appropriate proxy settings, for example: source -lt;Connector className=org.apache.catalina.connector.http.HttpConnector -port=8081 ... - proxyName=www.mycompany.com - proxyPort=80/gt; +lt;Connector port=8081 ... + proxyName=www.mycompany.com + proxyPort=80/gt; /source which will cause servlets inside this web application to think that all proxied requests were directed to codewww.mycompany.com/code - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ServletRequest.setCharacterEncoding() and GET parameters
Remy Maucherat wrote: Using different encoding for GET and POST parameters by default is counter-intuitive and breaks the Principle of least astonishment. If it is kept that way, the same bug will be reported again and again. -1. The attribute, now that it actually exists, is well documented. Rémy It is not included in the default server.xml available in CVS. It would help if it is included so that its existence and placement will be obvious. Also it is not displayed in the Administration Tool. The default setting breaks compatibility with older versions of TomCat and with all other web containers. So what is the reason for having that default value and not the other ? Martin -- ~~ Supercomputing Center Brno Martin Kuba Institute of Computer Scienceemail: [EMAIL PROTECTED] Masaryk University http://www.ics.muni.cz/~makub/ Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775 -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24545] - DataSourceRealm cannot see JNDI DataSource defined within a Context
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=24545. 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=24545 DataSourceRealm cannot see JNDI DataSource defined within a Context --- Additional Comments From [EMAIL PROTECTED] 2004-01-08 15:35 --- I'm trying to run a server with multiple instances of the same application configured for different customers. I need each application to have it's own datasource and realm. I can't see the logic in beeing able to create a context specific datasource and realm but not beeing able to use _that_ datasource _for_ the realm. I think the demand for a global datasource breaks the whole idea with the application specific configuration. The worst part is that Remy wont listen to reason neither explain why he refuses to add this feature. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25981] - jsp security example does not work!
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25981. 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=25981 jsp security example does not work! --- Additional Comments From [EMAIL PROTECTED] 2004-01-08 16:27 --- What in the world is, It works for me now supposed to mean? Does this mean it didn't work for you five minutes ago, it always worked. This is a very default install with I would thing everything required to make it work internal to the installation. I have seen nothing that indicates that there needs to be any configuration? Are you running this from the linux platform? Are you using 5.0.16 Something a little more verbose might be nice, to let the user know that he hasn't been just blown off! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25981] - jsp security example does not work!
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25981. 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=25981 jsp security example does not work! --- Additional Comments From [EMAIL PROTECTED] 2004-01-08 16:34 --- Answering bug reports is (of course) always based on the current CVS code. Security constraint checking was updated since 5.0.16. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jk2 object model
The major mistake in jk2 is the 2 in the name. It was an error to fork ( even if it was easier to code and move it ) instead of improving mod_jk and adding/fixing. In JNI mode and from configuration perspective - as well as ability to use non-tcp-socket communation - jk2 is way ahead. As code organization and readability - besides the original OO model - jk2 is better. But it works as well as jk, and just like jk it works well enough - so I agree that at the moment they are dead from the point of the active development. I have a feeling even tomcat is getting close to this point, I can hardly find any major itch in tc5. We should probably use the term stable and done instead of dead :-) Regarding ease of use and fancy protocols - all this requires an object model. I agree that the current OO is not perfect, but it works without the dependencies other OO models would have ( XPCOM - NSPR - remember the fun in licence dicussions ). So I think the first question would be what to do about the object model, keep/improve the current one or switch to a (XP)COM-like ( or C++, or Gtk+ or OpenOffice ). After we have objects with JMX-like behavior, configuration and extension in any direction can follow the same model as tomcat. Should we call this jk+ or jk3 ? IMO it would be a major mistake, even bigger than for jk2. We have far fewer itches and less time, and a fork allways requires much bigger effort in addoption. The main reason people don't use jk2 is that jk1 works well enough for the task, plus different config. Same would happen to a jk3 - whenver this would be ready. So my suggestion ( deja vue ? ) is to use evolution :-). A change in the OO model ( if needed ) or fixing/improving the current one is not as big change as it seems - it's mostly in initialization code. Javaspaces, other protocols, other transports and other servers can be added at any time - but I think it would be vital to _add_ them to an existing base instead of adding yet another new connector. Costin Mladen Turk wrote: Hate to quote myself, but... As I said, the performance isn't a priority here, but rather usability. I'm sure that TC guys will be open here, and we will see (perhaps even in 5.1) the 'open TC API', that could be directly used, or seamlessly integrated from the native side. I would prefer to see that, rather then trying to 'discover' something, and after all it would 'stay in the house', since I wish to make a connector(integrator) for Tomcat, not for some xyz container. Of course this would imply the firm collaboration with the TC guys, but once again I don't wish to pack/unpack something over and over again (I have JK for that). The concept (approach) as I see it is to be able to make a connector (integrator), that would allow the zero-based-configuration. Meaning that loading a module (filter) will automatically map the Tomcat web space to the web server. No matter if the TC was started in or out of the process, and no matter how much clustered instances exists on different nodes. If there is developer interest for that, I'm willing to 'shake the things'. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jk2 object model
From: Costin Manolache So my suggestion ( deja vue ? ) is to use evolution :-). A change in the OO model ( if needed ) or fixing/improving the current one is not as big change as it seems - it's mostly in initialization code. How about 'revolution'? On the other hand how does the evolution differs from revolution? Javaspaces, other protocols, other transports and other servers can be added at any time - but I think it would be vital to _add_ them to an existing base instead of adding yet another new connector. I hate the word connector. I would like to name that new thing integrator (jakarta-tomcat-integrator, how that sounds?) It would IMO better describe that new approach (at least the one I have on my mind). and... If we don't put ourselfs out from 'reusable' concept, nothing new will ever be done thought. Trying to reclyle something, as you nicely said stable and done, is poinntless from the '(r)evolution' perspective. Either we'll do (like Monty Pyton's said) something completely different, or we'll be once again asking ourselfs the same questions for year or so, and the guys will still use the JK or swith to something else. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans MBeanFactory.java
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: amyroh 2004/01/07 21:32:25 Modified:catalina/src/share/org/apache/catalina/core StandardHost.java catalina/src/share/org/apache/catalina/mbeans MBeanFactory.java Log: Fix bugzilla 25878 - Add HostConfig after new Host is created via admin and prevent duplicate errorReportValve creation after restart. Patch submitted by [EMAIL PROTECTED] (Peter Rossbach). I thought the StandardHost patch wasn't super clean. I think keeping a reference to the valve (and removing it on stop using that) would likely be a lot better. I'll see if I can improve it. Sounds good. Amy Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans MBeanFactory.java
Amy Roh wrote: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: amyroh 2004/01/07 21:32:25 Modified:catalina/src/share/org/apache/catalina/core StandardHost.java catalina/src/share/org/apache/catalina/mbeans MBeanFactory.java Log: Fix bugzilla 25878 - Add HostConfig after new Host is created via admin and prevent duplicate errorReportValve creation after restart. Patch submitted by [EMAIL PROTECTED] (Peter Rossbach). I thought the StandardHost patch wasn't super clean. I think keeping a reference to the valve (and removing it on stop using that) would likely be a lot better. I'll see if I can improve it. Sounds good. Sorry, I didn't find any better solution (different ones, but not better). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exception in RealmBase
Mark Woon wrote:
Hi all,
I'm reposting this in the hopes that someone will responsd.
I have a custom Realm implementation that extends
org.apache.catalina.realm.RealmBase. It used to work in 4.x, but in
5.0.16, I'm getting the following exception on startup:
21:17:29,719 ERROR RealmBase:1092 - Can't register null
java.lang.NullPointerException
at org.apache.catalina.realm.RealmBase.init(RealmBase.java:1088)
at org.apache.catalina.realm.RealmBase.start(RealmBase.java:769)
at
org.pharmgen.webapp.tomcat.PharmGenRealmAdapter.setRealm(PharmGenRealmAdapter.java:34)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.securityfilter.config.SecurityConfig.addRealm(SecurityConfig.java:216)
[snip]
I've taken a look at the source, and as far as I can tell, it's because
the container is null. What is responsible for providing the Realm the
container it's in? Is there some new bit of configuration I need to do
in Tomcat 5? I'm also surprised that there's this bit of code in
RealmBase.init():
if( container== null ) {
// do some stuff, and don't set container or oname
}
if( oname==null ) {
try {
ContainerBase cb=(ContainerBase)container;
// NPE HAPPENS HERE
oname=new ObjectName(cb.getDomain()+:type=Realm +
cb.getContainerSuffix());
// some other stuff
} catch (Throwable e) {
log.error( Can't register + oname, e);
}
}
How are you adding your realm? It seems the code under container==null
should be executed when the realm is added via JMX using full object
name only. It's using its own object name to figure out its container
and calls setRealm to its container. When oname==null, the realm should
already have its container...
Amy
I don't have any experience with JMX, so maybe it's doing something
behind the scenes, but if not, that bit of code looks wrong. While this
seems to be an error that can be safely ignored if I'm not using JMX,
it's still a little distressing.
Any help would be appreciated.
Thanks,
-Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[kylev-jakarta@kylev.com: DataSourceRealm and Context defined JNDI Resource]
I'm re-forwarding this message to the list for (hopefully) discussion. I sent this the first time as 5.0 was going final, so people where very busy. I get very regular personal questions about this topic as people cull the list archives and find me. Also, I think I've seen two more bugs on the same issue opened and closed (INVALID/WONTFIX) recently. People (myself included) *really* don't understand why a Context-local JNDI Datasource isn't reasonable. - Forwarded message from Kyle VanderBeek [EMAIL PROTECTED] - Remy: I'm looking at two bugs (one of which I opened): http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16316 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24545 And it seems to have confused several people that DataSourceRealm can't use a JNDI Resource defined in a Context but must instead use a global resource. The matters that confuse are that 1) an administrator can define a Resource at the Context level and 2) a Realm is defined at a Context level. It seems to follow from these observations that a Realm should be able to use a JNDI Resource defined at the same level. This is possible with the small patch I submitted on bug 24545 (from my work address). It seems to work fine (contrary to your 2003-6-12 remark on bug 16316). In addition, this seems like a very useful functionality. Several people have brought up the security concern of placing their user database in a global JNDI resource. I also brought up the idea of turnkey applications that could be deployed using a DataSourceRealm without having to ask the client to make modifications to their server.xml: drop the context fragment and the .war in the right place and you're done. I've gotten emails about this expected functionality (related to my bug) and really don't have anything to tell people. Remy, I'd like to understand why you've so quickly closed these bugs WONTFIX. I don't see the issue. If there is a design problem with this, I'd like to know what it is. I was hoping for a dialogue from you and the other developers. In the end, maybe this is just an enhancement request. Regardless, it's probably good to get this (and hopefully a series of well-formed responses) in the archive. Thanks. - End forwarded message - -- [EMAIL PROTECTED] Some people have a way with words, while others... erm... thingy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24308] - for charset=UTF8 request.getParameter(i1).getBytes() return non UTF8 bytes
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=24308. 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=24308 for charset=UTF8 request.getParameter(i1).getBytes() return non UTF8 bytes --- Additional Comments From [EMAIL PROTECTED] 2004-01-08 21:01 --- I believe I have just hit this problem - but on a POST request. I had a form where the user entered a £ sign (UK currency symbol). When I carried out a request.getParameter(myParam);, the result came through with the funny A character preceding the currency symbol. Despite other reporters descriptions of this only occurring on a GET - my form was definately a POST. The workaround for me has been to use request.setCharacterEncoding(UTF8); - and now everything is fine. (Note: someone above reported this not to make any difference - you *must* call this prior to making any calls to getParameter() or, getReader() ) This was on tomcat 4.1.29 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jk2 object model
I agree that the current connectors (jk and jk2) are fairly stable and done because they just work. The hardest part in using them is that there is a lot of duplicated setup between the Java/Tomcat side and the webserver configuration just to get things working. Then, when you add a new webapp into Tomcat, you have to remember to update the webserver configuration to handle the application. I like what Mladen said here: The concept (approach) as I see it is to be able to make a connector (integrator), that would allow the zero-based-configuration. Meaning that loading a module (filter) will automatically map the Tomcat web space to the web server. No matter if the TC was started in or out of the process, and no matter how much clustered instances exists on different nodes. Can we do this by evolving mod_jk or mod_jk2? I don't know. I believe it is possible and agree with Costin that this is probably the better way to go because this is what our users recognize as the connector of choice. Look at what happened with mod_webapp. I think that Pier and and Jean-Frederic did some great work on this, but the community (developers and users) never really got behind it. I don't know if that is because it was too revolutionary or what. I'm just worried that if we break too far from jk, we'll end up going nowhere. If we can evolve mod_jk or mod_jk2 to allow zero-based-configuration as Mladen suggests, I think that is the path that we should follow. If we have to revolt :-) and re-architect, we need to make sure that what we produce is soo much better that people can't wait to get it and help plug it into their web server. This includes getting it running and working on as many OS platforms and webservers as possible right up front. If there is developer interest for that, I'm willing to 'shake the things'. I'm (finally :-) ready to start diving in and help shake things up. aside I got stuck doing the management thing for a couple of years so I couldn't (didn't :-( ) contribute as much but I'm back on this pretty much full time now - as an engineer, not a manager :-). /aside Mike Anderson Sr. Software Engineer [EMAIL PROTECTED] Novell, Inc., The leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] 1/8/2004 10:16:03 AM From: Costin Manolache So my suggestion ( deja vue ? ) is to use evolution :-). A change in the OO model ( if needed ) or fixing/improving the current one is not as big change as it seems - it's mostly in initialization code. How about 'revolution'? On the other hand how does the evolution differs from revolution? Javaspaces, other protocols, other transports and other servers can be added at any time - but I think it would be vital to _add_ them to an existing base instead of adding yet another new connector. I hate the word connector. I would like to name that new thing integrator (jakarta-tomcat-integrator, how that sounds?) It would IMO better describe that new approach (at least the one I have on my mind). and... If we don't put ourselfs out from 'reusable' concept, nothing new will ever be done thought. Trying to reclyle something, as you nicely said stable and done, is poinntless from the '(r)evolution' perspective. Either we'll do (like Monty Pyton's said) something completely different, or we'll be once again asking ourselfs the same questions for year or so, and the guys will still use the JK or swith to something else. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 CoyoteConnector.java
remm2004/01/08 14:50:32 Modified:coyote/src/java/org/apache/coyote/tomcat4 CoyoteConnector.java Log: - For the TC 4.1 branch, use the same default as in TC 4.1.27. Revision ChangesPath 1.29 +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.28 retrieving revision 1.29 diff -u -r1.28 -r1.29 --- CoyoteConnector.java 12 Dec 2003 02:44:34 - 1.28 +++ CoyoteConnector.java 8 Jan 2004 22:50:32 - 1.29 @@ -360,7 +360,7 @@ /** * URI encoding as body. */ - private boolean useBodyEncodingForURI = false; + private boolean useBodyEncodingForURI = true; // - Properties - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24308] - for charset=UTF8 request.getParameter(i1).getBytes() return non UTF8 bytes
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=24308. 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=24308 for charset=UTF8 request.getParameter(i1).getBytes() return non UTF8 bytes [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-08 22:51 --- This is a regression in the 4.1.x branch, and will be fixed in the next release. Sorry about this problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JMX JRMP rmi registry port configuration
When JMX is enabled, in the jk2.properties file, and configured to use the MX4J JRMP interal adapter, a rmi registry is created and bound to the default port of 1099. If there is another application using that port and bind expection is thrown and the adaptor is never enabled. A configuration option for the rmi registry port would sovle this problem. A setter for port does exist on the mx4j.tools.naming.NamingService object. The lastest source for org.apache.jk.common.JkMX does not have this feature, and would be the place to incorporate it. This is my first post to the mailing list and have been a long time user of Tomcat. -Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10563] - Multiple compiles for multiple requests
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=10563. 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=10563 Multiple compiles for multiple requests [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-01-08 23:48 --- *** This bug has been marked as a duplicate of 14077 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14077] - JSP class corruption when compiling page on SMP server
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=14077. 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=14077 JSP class corruption when compiling page on SMP server --- Additional Comments From [EMAIL PROTECTED] 2004-01-08 23:48 --- *** Bug 10563 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26006] New: - Friendlier error message for Illegal target of jump or branch
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=26006. 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=26006 Friendlier error message for Illegal target of jump or branch Summary: Friendlier error message for Illegal target of jump or branch Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Enhancement Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We had a developer get bitten by this today, and I remember getting bitten with it a while ago, so I thought I'd post a suggestion. When you create a JSP that's too big that causes the generated method to go past the 64K limit you get an error like this: - javax.servlet.ServletException: (class: org/apache/jsp/desktop_0005fresults_0005fdetail$jsp, method: _jspService signature: (Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V) Illegal target of jump or branch at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:481) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:683) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:431) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:355) at com.templar.it.fed.dm.AbstractDfmDisplayManager.forwardToPage(AbstractDfmDisplayManager.java:408) at com.templar.it.fed.dm.AbstractDfmDisplayManager.doGet(AbstractDfmDisplayManager.java:392) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) My suggested enhancement is to check for that specific illegal jump error and if it happens, append an error message like Your JSP file may have generated a method larger than 64K. Please visit this FAQ/use jsp:include/ etc etc Just a suggestion. thanks! john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX JRMP rmi registry port configuration
The option mx.jrmpPort is used for registering the JRMPAdaptor to the NamingService, by setting the PROVIDER_URL. When the NamingService is regeristered it creates the rmi registry whiCh defaults to 1099. The code below will show what I mean about setting the port on the rmi registry. The code below is from the class org.apache.jk.common.JkMX. snip jrmpServerName = new ObjectName(Naming:name=rmiregistry); mserver.createMBean(mx4j.tools.naming.NamingService, jrmpServerName, null); // new line to set the rmi registry port to 1199 server.setAttribute(naming, new Attribute(Port, new Integer(1199))); mserver.invoke(jrmpServerName, start, null, null); log.info( Creating + jrmpServerName ); /snip -Kevin Bill Barker wrote: - Original Message - From: Kevin Pfarr [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 08, 2004 2:55 PM Subject: JMX JRMP rmi registry port configuration When JMX is enabled, in the jk2.properties file, and configured to use the MX4J JRMP interal adapter, a rmi registry is created and bound to the default port of 1099. If there is another application using that port and bind expection is thrown and the adaptor is never enabled. A configuration option for the rmi registry port would sovle this problem. A setter for port does exist on the mx4j.tools.naming.NamingService object. The lastest source for org.apache.jk.common.JkMX does not have this feature, and would be the place to incorporate it. Actually, it does have this feature already. The option you want is: mx.jrmpPort=port-number This is my first post to the mailing list and have been a long time user of Tomcat. -Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Kevin Pfarr Software Engineer PN: 314.678.2231 FX: 314.436.2559 CELL: 314.629.6255 [EMAIL PROTECTED] Asynchrony Solutions, Inc. 1709 Washington Avenue // Suite 200 Saint Louis, Missouri 63103 www.asolutions.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11909] - The memory and resident memory size increases for the new connector
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=11909. 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=11909 The memory and resident memory size increases for the new connector [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-01-09 00:16 --- Various tests (see tomcat-user and tomcat-dev archives) to track down the request dispatcher memory leak in 4.1.x prior to 4.1.6 didn't identify any leak with the coyote connector. Is it possible what you are seeing is just a larger memory footprint for the CoyoteConnector compared to the HttpConnector? If there was a memory leak I would expect to see the total memory increase usage over time under constant load. This is not what you describe. I am going to mark this as invalid for now. If you are experiencing a memory leak then we will need a much better description of your test case if we are to stand any chance at all of tracking it down. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exception in RealmBase
Amy Roh wrote:
Mark Woon wrote:
I've taken a look at the source, and as far as I can tell, it's because
the container is null. What is responsible for providing the Realm the
container it's in? Is there some new bit of configuration I need to do
in Tomcat 5? I'm also surprised that there's this bit of code in
RealmBase.init():
if( container== null ) {
// do some stuff, and don't set container or oname
}
if( oname==null ) {
try {
ContainerBase cb=(ContainerBase)container;
// NPE HAPPENS HERE
oname=new ObjectName(cb.getDomain()+:type=Realm +
cb.getContainerSuffix());
// some other stuff
} catch (Throwable e) {
log.error( Can't register + oname, e);
}
}
How are you adding your realm? It seems the code under container==null
should be executed when the realm is added via JMX using full object
name only. It's using its own object name to figure out its container
and calls setRealm to its container.
I'm not sure what you mean by adding your realm exactly, but I just
defined it in server.xml. I've tried putting the Realm element as a
child of Engine, Host and Context, and all have produced the same
exception.
When oname==null, the realm should
already have its container...
Exactly. What is responsible for providing the container to the Realm?
-Mark
cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/tcp ReplicationListener.java SimpleTcpCluster.java TcpReplicationThread.java
fhanik 2004/01/08 18:50:54
Modified:modules/cluster/src/share/org/apache/catalina/cluster/mcast
McastService.java
modules/cluster/src/share/org/apache/catalina/cluster/tcp
ReplicationListener.java SimpleTcpCluster.java
TcpReplicationThread.java
Log:
fixed 100% cpu bug with the replication listener. We don't want to listen to
OP_WRITE events at all. Added a bind address to the broadcast address
Revision ChangesPath
1.5 +9 -5
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/mcast/McastService.java
Index: McastService.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/mcast/McastService.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- McastService.java 18 Dec 2003 04:20:14 - 1.4
+++ McastService.java 9 Jan 2004 02:50:54 - 1.5
@@ -166,10 +166,14 @@
int port = Integer.parseInt(getProperties().getProperty(tcpListenPort));
String name = tcp://+host+:+port;
localMember = new McastMember(name,host,port,100);
+java.net.InetAddress bind = null;
+if ( properties.getProperty(mcastBindAddress)!= null ) {
+bind =
java.net.InetAddress.getByName(properties.getProperty(mcastBindAddress));
+}
impl = new
McastServiceImpl((McastMember)localMember,Long.parseLong(properties.getProperty(msgFrequency)),
Long.parseLong(properties.getProperty(memberDropTime)),
Integer.parseInt(properties.getProperty(mcastPort)),
-null,
+bind,
java.net.InetAddress.getByName(properties.getProperty(mcastAddress)),
this);
1.8 +12 -5
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/tcp/ReplicationListener.java
Index: ReplicationListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/tcp/ReplicationListener.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- ReplicationListener.java 20 Dec 2003 00:48:52 - 1.7
+++ ReplicationListener.java 9 Jan 2004 02:50:54 - 1.8
@@ -144,7 +144,9 @@
// selected set contains keys of the ready channels
try {
+//System.out.println(Selecting with timeout=+timeout);
int n = selector.select(timeout);
+//System.out.println(select returned=+n);
if (n == 0) {
continue; // nothing to do
}
@@ -160,18 +162,23 @@
SocketChannel channel = server.accept();
registerChannel(selector,
channel,
-SelectionKey.OP_READ |
-SelectionKey.OP_WRITE,
+SelectionKey.OP_READ,
new ObjectReader(channel, selector,
callback));
}
// is there data to read on this channel?
+//System.out.println(key readable=+key.isReadable());
if (key.isReadable()) {
readDataFromSocket(key);
+} else {
+//System.out.println(This shouldn't get called);
+key.interestOps(key.interestOps() (~key.OP_WRITE));
}
+
// remove key from selected set, it's been handled
it.remove();
}
+System.out.println(Done with loop);
}
catch (java.nio.channels.CancelledKeyException nx) {
log.warn(
1.22 +9 -4
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/tcp/SimpleTcpCluster.java
Index: SimpleTcpCluster.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/tcp/SimpleTcpCluster.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- SimpleTcpCluster.java 18 Dec 2003 04:20:15 - 1.21
+++ SimpleTcpCluster.java 9 Jan 2004 02:50:54 - 1.22
@@ -611,6 +611,11 @@
cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/tcp ReplicationListener.java
fhanik 2004/01/08 18:53:08
Modified:modules/cluster/src/share/org/apache/catalina/cluster/tcp
ReplicationListener.java
Log:
removed println
Revision ChangesPath
1.9 +4 -4
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/tcp/ReplicationListener.java
Index: ReplicationListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/tcp/ReplicationListener.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- ReplicationListener.java 9 Jan 2004 02:50:54 - 1.8
+++ ReplicationListener.java 9 Jan 2004 02:53:08 - 1.9
@@ -178,7 +178,7 @@
// remove key from selected set, it's been handled
it.remove();
}
-System.out.println(Done with loop);
+//System.out.println(Done with loop);
}
catch (java.nio.channels.CancelledKeyException nx) {
log.warn(
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26010] New: - context path in server.xml doesn't like _ (underscore) character.
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=26010. 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=26010 context path in server.xml doesn't like _ (underscore) character. Summary: context path in server.xml doesn't like _ (underscore) character. Product: Tomcat 5 Version: Nightly Build Platform: PC OS/Version: Linux Status: NEW Severity: Minor Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] stdout and logs/localhost_log.[date].txt complain when a context path attribute contains a _ (underscore) character. The webapp still deploys fine. The error messages are annoying, that's all! :-) This generates error messages (in server.xml): Context path=/test_ debug=0 docBase=/stuff/empty/ This doesn't: Context path=/test debug=0 docBase=/stuff/empty/ stdout: == INFO: Processing Context configuration file URL file:/home/juliusdavies/jakarta-tomcat-5/conf/Catalina/localhost/test_.xml 8-Jan-2004 7:06:23 PM org.apache.commons.digester.Digester endElement SEVERE: End event threw exception java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [...] Caused by: java.lang.IllegalStateException: Context path /test_ is already in use at org.apache.catalina.core.StandardHostDeployer.addChild(StandardHostDeployer.java:833) ... 38 more logs/localhost_log.[date].txt: == 2004-01-08 19:06:23 StandardHost[localhost]: Error deploying application at context path null java.lang.IllegalStateException: Context path /test_ is already in use at org.apache.commons.digester.Digester.createSAXException(Digester.java:2540) * Version jakarta-tomcat-5-bin-20040107 * Tomcat component org.apache.catalina.core.StandardHostDeployer.addChild * Platform PC (Intel Pentium III) * OS Linux 2.4.18 (Debian) * JVM Java HotSpot(TM) Server VM (build 1.4.2-b28, mixed mode) * Web Server Tomcat 5.0 listening on port 8080 * Configuration No change to default except single line: Context path=/test_ debug=0 docBase=/stuff/empty/ ps. Am I seeing things? I noticed that deleting a Context from server.xml doesn't actually remove the webapp from service! The webapp will still deploy on Tomcat's next run. Tomcat seems to use the conf/Catalina/**/*.xml files it creates to accomplish this. I get a feeling that context inside server.xml is sort of deprecated, and that I should just create individual context xml files inside conf/Catalina/ instead. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jk2 object model
Mladen Turk wrote: From: Costin Manolache So my suggestion ( deja vue ? ) is to use evolution :-). A change in the OO model ( if needed ) or fixing/improving the current one is not as big change as it seems - it's mostly in initialization code. How about 'revolution'? On the other hand how does the evolution differs from revolution? My point was that fixing/improving the current code - maybe by first fixing the object model, then adding modules - is better than starting from scratch or trying to make a huge change at once. and... If we don't put ourselfs out from 'reusable' concept, nothing new will ever be done thought. Trying to reclyle something, as you nicely said stable and done, is poinntless from the '(r)evolution' perspective. It's not recycle - but improve. And I don't know why you feel it's pointless. Either we'll do (like Monty Pyton's said) something completely different, or we'll be once again asking ourselfs the same questions for year or so, and the guys will still use the JK or swith to something else. Doing something completely different for the sake of doing it different and without understanding or knowing what is wrong with the current approach is not going to lead us to something better - just different. So far I haven't heard any concrete proposal of doing something different - just nice goals ( easier config, etc ). IMO using JMX-like model you can support almost any config needs - zeroconf/randezvous/etc. And the performance is result of lots of work and tunning - I never seen any rewrite from scratch, completely different project to be faster ( at least not in less than few years ). Same for stability BTW. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
