Re: Jk2 object model
- Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 08, 2004 8:51 PM Subject: 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. You pushed for an 'evolution' for TC5, and look what it got us: The most stable Tomcat GA release ever ;-). 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. Could actually be said for much of Jk2. However, the Jk2 code is much more maintainable, so I'd prefer to 'evolve' from there. The reasons that I'm sticking to Jk1 for all of my production servers are pretty small, and fixable. 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. Well, to be a little nicer than Costin, so far we have seen an abstract idea of sending the request to Tomcat to ask if it wants to map it (avoiding the double-mapping that we do now). However, the revolutionaries out there need to put together a [PROPOSAL] first before there can be a decision on revolusion vs. evolusion. There is a page on the Jakarta site spelling this out, from the last time this issue almost split this community apart :). Costin - 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]
Re: Jk2 object model
Mike Anderson wrote: 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. The mean problem was using an instable APR API. Another difference between mod_webapp and mod_jk/mod_jk2 was the thinking to have a Servlet Engine as an extention of Apache not a connector between Tomcat and Apache. The other good thing of mod_webapp is to have a good protocol (WARP). May be we can reuse it in the new connector. BTW: I am using mod_jk2. 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] - 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 --- Additional Comments From [EMAIL PROTECTED] 2004-01-09 08:20 --- Thank you very much for the detailed explanation. Though I'm pretty sure all ppl that post here understand the matter. The question is: can we hope this normal situation to be reported in logs with stack-traces only under certain debug level and be just skipped at debug level 0 of the connector? Sorry for bothering you again. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jk2 object model
-Original Message- From: jean-frederic clere Sent: 9. sijeanj 2004 8:35 To: Tomcat Developers List Subject: Re: Jk2 object model The concept (approach) as I see it is to be able to make a connector (integrator), that would allow the zero-based-configuration. Meaning Can we do this by evolving mod_jk or mod_jk2? I don't know. The other good thing of mod_webapp is to have a good protocol (WARP). May be we can reuse it in the new connector. You see, those are thinks I wish to investigate. JK2 has a good OO model, the JK has simplicity, webapp has a good protocol, but that doesn't mean that either of them has all that's needed (at least from my perspective). I agree that the 'evolution' is the most pragmatic approach, but again to 'evolutes' from what? If some (or all) codebases will enable to use the TC not only in webserver, but in the simple console app, that's fine. If we find a way (extending the AJP protocol thought) to allow zero-based-admin for existing connectors, that's fine too. Something like, will ask for developer support, that if missed will eventually 'stabilize' the project. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [kylev-jakarta@kylev.com: DataSourceRealm and Context defined JNDI Resource]
Kyle, I agree with you on this. I'd like to draw a parallel with the classloader and how it treats the classes in the common area and classes in a webapp. (please correct me if I'm wrong) If I put a class (database driver etc) in the common/lib area tomcat can use it *and* my web app can. Direct parallel : I can define a resource in globalresources and use tomcat can use it for the global realm and my web app can use it for its context based realm. If I put a class in my webapps lib area My webapp can use it but tomcat cannot see it. If I define a resource at the context level why can't my web app use it for a realm ? I seems a little inconsistent to me. But if I'm missing the point please please tell me why (The only thing I can think of is if you are making a global realm the code doing the lookup will need to restrict its search to just the global resources rather than using the initial context as well. but ... ?? ) Kind regards David Cassidy Kyle VanderBeek [EMAIL PROTECTED]To: [EMAIL PROTECTED] lev.com cc: Subject: [EMAIL PROTECTED]: DataSourceRealm and Context defined JNDI Resource] 08/01/2004 20:52 Please respond to Tomcat Developers List 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
DO NOT REPLY [Bug 26010] - 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. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER --- Additional Comments From [EMAIL PROTECTED] 2004-01-09 10:05 --- Yes, for now, '_' can't be freely used in a context path, sorry. This will not be fixed for a while. Use '-' instead. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session JDBCStore.java LocalStrings.properties
remm2004/01/09 03:35:08
Modified:catalina/src/share/org/apache/catalina/session
JDBCStore.java LocalStrings.properties
Log:
- Allow configuring users and passwords.
- Automatically reconnect if connection fails for some reason.
- Please review :)
- Bug 25889.
- Submitted by Peter Rossbach.
- I think we would need to add a DataSource based persistent store (this way,
it would have mush better scalability, and would not need to care about the
reconnect logic).
Revision ChangesPath
1.7 +457 -331
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/JDBCStore.java
Index: JDBCStore.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/JDBCStore.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- JDBCStore.java2 Sep 2003 21:22:01 - 1.6
+++ JDBCStore.java9 Jan 2004 11:35:08 - 1.7
@@ -64,6 +64,12 @@
package org.apache.catalina.session;
+import org.apache.catalina.Container;
+import org.apache.catalina.LifecycleException;
+import org.apache.catalina.Loader;
+import org.apache.catalina.Session;
+import org.apache.catalina.Store;
+import org.apache.catalina.util.CustomObjectInputStream;
import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.ByteArrayInputStream;
@@ -73,18 +79,12 @@
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.sql.Connection;
-import java.sql.DriverManager;
+import java.sql.Driver;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.util.ArrayList;
-
-import org.apache.catalina.Container;
-import org.apache.catalina.LifecycleException;
-import org.apache.catalina.Loader;
-import org.apache.catalina.Session;
-import org.apache.catalina.Store;
-import org.apache.catalina.util.CustomObjectInputStream;
+import java.util.Properties;
/**
* Implementation of the codeStore/code interface that stores
@@ -96,7 +96,7 @@
*/
public class JDBCStore
-extends StoreBase implements Store {
+extends StoreBase implements Store {
/**
* The descriptive information about this implementation.
@@ -119,14 +119,30 @@
protected String threadName = JDBCStore;
/**
+ * The connection username to use when trying to connect to the database.
+ */
+protected String connectionName = null;
+
+
+/**
+ * The connection URL to use when trying to connect to the database.
+ */
+protected String connectionPassword = null;
+
+/**
* Connection string to use when connecting to the DB.
*/
-protected String connString = null;
+protected String connectionURL = null;
/**
* The database connection.
*/
-private Connection conn = null;
+private Connection dbConnection = null;
+
+/**
+ * Instance of the JDBC Driver class we use as a connection factory.
+ */
+protected Driver driver = null;
/**
* Driver to use.
@@ -208,7 +224,7 @@
* Return the info for this Store.
*/
public String getInfo() {
-return(info);
+return (info);
}
/**
@@ -237,14 +253,14 @@
* Return the thread name for this Store.
*/
public String getThreadName() {
-return(threadName);
+return (threadName);
}
/**
* Return the name for this Store, used for logging.
*/
public String getStoreName() {
-return(storeName);
+return (storeName);
}
/**
@@ -256,8 +272,8 @@
String oldDriverName = this.driverName;
this.driverName = driverName;
support.firePropertyChange(driverName,
- oldDriverName,
- this.driverName);
+oldDriverName,
+this.driverName);
this.driverName = driverName;
}
@@ -265,7 +281,41 @@
* Return the driver for this Store.
*/
public String getDriverName() {
-return(this.driverName);
+return (this.driverName);
+}
+
+/**
+ * Return the username to use to connect to the database.
+ *
+ */
+public String getConnectionName() {
+return connectionName;
+}
+
+/**
+ * Set the username to use to connect to the database.
+ *
+ * @param connectionName Username
+ */
+public void setConnectionName(String connectionName) {
+this.connectionName = connectionName;
+}
+
+/**
+ * Return
DO NOT REPLY [Bug 25889] - JDBCStore hsqldb 1.7.1 connection faild and no connection reconnect after failed
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=25889. 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=25889 JDBCStore hsqldb 1.7.1 connection faild and no connection reconnect after failed [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-09 11:35 --- I've applied your patch, which looked ok, but couldn't test it. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ServletRequest.setCharacterEncoding() and GET parameters
Jess Holle wrote: Remy Maucherat wrote: -1. The attribute, now that it actually exists, is well documented. Yes, but the default behavior should be for setCharacterEncoding() to work according to general JSP/servlet usage recommendation e.g.: http://java.sun.com/developer/technicalArticles/Intl/MultilingualJSP/. If there are reasons this is unworkable, then these should be worked out with Sun so they stop telling everyone that this approach works. Until then obnoxious ignoramouses like me will try to do what Sun says, fail with Tomcat, and blame Tomcat. -- Jess Holle This is getting ridiculous. Both sides have strong arguments. I hadn't thought about this issue until tomcat changed it's behaviour, and maybe the Sun folks didn't do it as well. This should really be clarified within the specification (and I hope they come up with a solution that allows us to continue using GET parameters as we were used to as this is an absolute necessity... maybe by introducing a new method or a second parameter). Although I do not expect too much, I 've just sent a comment to JSR53 and JSR154 I just hope that the new tomcat versions will be released soon Stefanos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problems With Deployment
Hi, I am a university student doing my thesis which involves the development of a dynamic web application using Apache Tomcat. At this point, I have completed the development of the web application on Windows 2000 (using jakarta-tomcat-5.0.16). I'm currently attempting to deploy the web application on linux, but am encountering problems. I have installed jakarta-tomcat-5.0.16 on linux, and have set the environment variable: JAVA_HOME to the proper path. I have transferred the entire directory /ACF from the windows apache tomcat to the linux apache tomcat. However, when I attempt to access a servlet through the web browser (http://localhost:8080/ACF), i get a 404 error: HTTP Status 404 - /ACF The requested resource (/ACF) is not available. The Web Server cannot find the index.html file!!! Even when i direct it to the proper location, I still receive the 404 error: The requested resource (/ACF/index.html) is not available. I read through the documentation and can't seem to find a solution. Your help in this matter is much appreciated, -Bernard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 release
-Original Message- From: jean-frederic clere Subject: jk2 release Hi, Is it correct that the lastest Jk2 release is from 27-Nov-2002? (2.0.2 tagged JK2_2_0_2) See? What is about making a newer one? We adopted the APR as mandatory. There are few things that are left open, like what is the minimum supported version, and the NIX build is broken. The problem is with the fact that APR has few patches (in CVS) that are needed for JK2 to operate in the new sense, but there is no official APR release (at least until the 0.95 is out). When we resolve those issues we can release. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems With Deployment
Did you configure $TOMCAT_HOME/conf/tomcat-apache.conf ? (tomcat-apache.conf might be hiding in /usr/local/apache/conf) Take a look at configuring Struts for Tomcat at http://jakarta.apache.org/struts/userGuide/installation-tc.html Let me know how you make out, Martin - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 08, 2004 4:36 PM Subject: Problems With Deployment Hi, I am a university student doing my thesis which involves the development of a dynamic web application using Apache Tomcat. At this point, I have completed the development of the web application on Windows 2000 (using jakarta-tomcat-5.0.16). I'm currently attempting to deploy the web application on linux, but am encountering problems. I have installed jakarta-tomcat-5.0.16 on linux, and have set the environment variable: JAVA_HOME to the proper path. I have transferred the entire directory /ACF from the windows apache tomcat to the linux apache tomcat. However, when I attempt to access a servlet through the web browser (http://localhost:8080/ACF), i get a 404 error: HTTP Status 404 - /ACF The requested resource (/ACF) is not available. The Web Server cannot find the index.html file!!! Even when i direct it to the proper location, I still receive the 404 error: The requested resource (/ACF/index.html) is not available. I read through the documentation and can't seem to find a solution. Your help in this matter is much appreciated, -Bernard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26021] New: - swallowoutput 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=26021. 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=26021 swallowoutput not working Summary: swallowoutput not working Product: Tomcat 4 Version: 4.1.29 Platform: All OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The tomcat installer creates windows registry values for the tomcat service start and stop classes, and swallowoutput does not work. Change org.apache.catalina.startup.BootstrapService to org.apache.catalina.startup.Bootstrap then swallowoutput works again. - 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 --- Additional Comments From [EMAIL PROTECTED] 2004-01-09 14:53 --- The latest release of Tomcat 4 only logs a single line for this exception rather than the entire stack trace, here is an example. 2004-01-09 07:49:12 Ajp13Processor[8009][49] process: IOException Broken pipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26022] New: - background compile thread compiles pages with errors on every run
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=26022.
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=26022
background compile thread compiles pages with errors on every run
Summary: background compile thread compiles pages with errors on
every run
Product: Tomcat 4
Version: 4.1.29
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
hi,
imagine i've got my jasper configured to use thee background compile thread that
runs every 300 secons, and imagine that there is a JSP page with an error inside
that makes it uncompilable. Than the jasper will compile the every 300 seconds
and will also create a log-entry every 300 seconds. jasper should somehow
remember that he tried that JSP already, for example by using a dummy class file
like
class XYZ {
static {
throw new RuntimeException(this page had compilation errors);
}
}
If this hasn't been fixed in Tomcat 5 yet, than of course this also applies for
Tomcat 5 too. You may also say that this is more a RFE than a Bug, but the
current behaviour is really stupid.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat is VERY new to me
Hi... Well, I am a developer. I am working with the apache since 1999. My company and I developed an application in Visual C++. We did a console application that works with the apache. The internet viewr sends a request. The request goes to the apache. The apache forwords this data to our app. Our app analyzed that data. and Using our database (Some text files) An answer was built and sent back to the apache and back to the user. This is all the expirience I have with dynamic HTML (XSL) and Databases (Text files). My dream is: to create a web site...that has access to database. without using a console application that will do it. I heared about JSP and Tomcat. and I think my dream is about to come true. I installed the JDK and Tomcat-5... and it seems to work... because i can see the main page of this address using my browser : http://127.0.0.1:8080/ so... my next step... Is to create my own database... and a jsp file that should generate an HTML using this DB. Any tips that will help me continue to the next stage... will be mostly appriciated... 10x The_Server. BTW: Thank you very much for this and others freewares...
Re: Tomcat is VERY new to me
The best information you can have is to re-sent your email to: [EMAIL PROTECTED] The dev is not for such questions, and you will have a very fast answer on the user list. -- Jeanfrancois Its Magic wrote: Hi... Well, I am a developer. I am working with the apache since 1999. My company and I developed an application in Visual C++. We did a console application that works with the apache. The internet viewr sends a request. The request goes to the apache. The apache forwords this data to our app. Our app analyzed that data. and Using our database (Some text files) An answer was built and sent back to the apache and back to the user. This is all the expirience I have with dynamic HTML (XSL) and Databases (Text files). My dream is: to create a web site...that has access to database. without using a console application that will do it. I heared about JSP and Tomcat. and I think my dream is about to come true. I installed the JDK and Tomcat-5... and it seems to work... because i can see the main page of this address using my browser : http://127.0.0.1:8080/ so... my next step... Is to create my own database... and a jsp file that should generate an HTML using this DB. Any tips that will help me continue to the next stage... will be mostly appriciated... 10x The_Server. BTW: Thank you very much for this and others freewares... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26025] New: - Jasper leaks file descriptors when checking for outdated pages
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=26025.
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=26025
Jasper leaks file descriptors when checking for outdated pages
Summary: Jasper leaks file descriptors when checking for outdated
pages
Product: Tomcat 4
Version: 4.0 Beta 1
Platform: Sun
OS/Version: Solaris
Status: NEW
Severity: Major
Priority: Other
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Every time Jasper checks for modified pages, it opens a URL connection to that
resource to check the modification time and never closes it. Normally it's not
a problem, since the FD will be freed when the object is garbage collected.
However, when running on systems with more heap and less frequent GC events,
the system runs out of FDs before the GC is invoked.
I noticed this problem in Jetty4.2.6, never with Tomcat. I'm providing a patch
for this problem when the WAR file is extracted. When this is not the case, I
don't know how to fix it. The patch follows.
--- Compiler.java.orig Mon Oct 27 16:24:08 2003
+++ Compiler.java Thu Jan 8 15:17:42 2004
@@ -63,6 +63,8 @@
import java.util.*;
import java.io.*;
import java.net.URL;
+import java.net.URLConnection;
+
import javax.servlet.jsp.tagext.TagInfo;
import javax.servlet.ServletException;
import javax.servlet.Servlet;
@@ -407,7 +409,11 @@
ctxt.incrementRemoved();
return false;
}
-jspRealLastModified = jspUrl.openConnection().getLastModified();
+
+// FIX: closes the stream to avoid FD leak
+URLConnection conn = jspUrl.openConnection();
+jspRealLastModified = conn.getLastModified();
+conn.getInputStream().close();
} catch (Exception e) {
e.printStackTrace();
return true;
@@ -468,11 +474,15 @@
//System.out.println(Compiler: outdated, no includeUri
+ include );
return true;
}
-if (includeUrl.openConnection().getLastModified()
-targetLastModified) {
+// FIX: closes the stream to avoid FD leak
+URLConnection conn = includeUrl.openConnection();
+if(conn.getLastModified() targetLastModified)
+{
+conn.getInputStream().close();
//System.out.println(Compiler: outdated, include old +
include );
return true;
}
+conn.getInputStream().close();
} catch (Exception e) {
e.printStackTrace();
return true;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26025] - Jasper leaks file descriptors when checking for outdated pages
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=26025. 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=26025 Jasper leaks file descriptors when checking for outdated pages --- Additional Comments From [EMAIL PROTECTED] 2004-01-09 17:10 --- The patch is provided against 4.1.29 release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26025] - Jasper leaks file descriptors when checking for outdated pages
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=26025. 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=26025 Jasper leaks file descriptors when checking for outdated pages [EMAIL PROTECTED] changed: What|Removed |Added Version|4.0 Beta 1 |4.1.29 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Solving bug 25822 : tomcat shouldn't write tomcat-users.xml at startup
According to last comment from Remy Maucherat, the first proposed patch was going in the right direction : [EMAIL PROTECTED] wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25822 --- Additional Comments From [EMAIL PROTECTED] 2004-01-05 16:21 -- Your first patch works fine (at least it does what I wanted): the users are no longer saved on startup, while updates using the admin webapp cause the file to be saved. Then I submitted a patch to correct this first patch and make it work perfectly. Let me know what you think from it and wether it could be submitted. Thanks. Xavier Poinsard. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ServletRequest.setCharacterEncoding() and GET parameters
Martin Kuba wrote: Stefanos Karasavvidis wrote: This is getting ridiculous. Both sides have strong arguments. I hadn't thought about this issue until tomcat changed it's behaviour, and maybe the Sun folks didn't do it as well. This should really be clarified within the specification (and I hope they come up with a solution that allows us to continue using GET parameters as we were used to as this is an absolute necessity... maybe by introducing a new method or a second parameter). Although I do not expect too much, I 've just sent a comment to JSR53 and JSR154 Sorry, nobody answered my previous question. What is the strong argument for breaking backward compatibility ? The RFC 2396 (URI syntax) in part 2.1 URI and non-ASCII characters states that: However, there is currently no provision within the generic URI syntax to accomplish this identification. An individual URI scheme may require a single charset, define a default charset, or provide a way to indicate the charset used. It is expected that a systematic treatment of character encoding within URI will be developed as a future modification of this specification. It means that URL character encoding is not defined by standards. So the only problem which I see is that Tomcat suddenly breaks the de facto standard used for last ten years and tries to stop application to use GET parameters. The decision has been made and was argumented. Please look into the archives of the mailing list. Please stop whining, this will not be changed. Since I wasted too much time already on this, I will ignore all subsequent threads/reply/etc on this particular subject, and will vote -1 to any proposal to change this. If you cannot be bothered into adding a parameter in the configuration file to enable the behavior you want, I suggest you try to look for another server. The change to the 4.1.x branch was not intended, and is a bug. The change to the 5.0.x branch was on purpose (and is a new branch, so expect at least *some* changes in behavior). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11271] - Filter was ignored while using FORM authentication?
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=11271. 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=11271 Filter was ignored while using FORM authentication? [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-01-09 22:56 --- Bug 21795 has a detailed discussion of why this is the way it is. *** This bug has been marked as a duplicate of 21795 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters
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=21795. 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=21795 j_security_check isn't fed through filters [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-01-09 22:56 --- *** Bug 11271 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 12179] - Deployer.REMOVE_EVENT is not implemented in StandardHost
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=12179. 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=12179 Deployer.REMOVE_EVENT is not implemented in StandardHost [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-09 23:06 --- This is imlemented in the latest versions of TC4 and TC5. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/tcp PooledSocketSender.java IDataSenderFactory.java SimpleTcpCluster.java SocketSender.java TcpReplicationThread.java ThreadPool.java
fhanik 2004/01/09 15:24:09
Modified:modules/cluster/src/share/org/apache/catalina/cluster/io
ObjectReader.java XByteBuffer.java
modules/cluster/src/share/org/apache/catalina/cluster/session
SimpleTcpReplicationManager.java
modules/cluster/src/share/org/apache/catalina/cluster/tcp
IDataSenderFactory.java SimpleTcpCluster.java
SocketSender.java TcpReplicationThread.java
ThreadPool.java
Added: modules/cluster/src/share/org/apache/catalina/cluster/tcp
PooledSocketSender.java
Log:
Implemented socket pool for replication since the synchronized
send became a bottleneck. This is a dramatic performance improvement
Revision ChangesPath
1.4 +9 -8
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/io/ObjectReader.java
Index: ObjectReader.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/io/ObjectReader.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ObjectReader.java 19 Dec 2003 21:22:13 - 1.3
+++ ObjectReader.java 9 Jan 2004 23:24:08 - 1.4
@@ -105,6 +105,11 @@
public int append(byte[] data,int off,int len) throws java.io.IOException {
boolean result = false;
buffer.append(data,off,len);
+int pkgCnt = buffer.countPackages();
+return pkgCnt;
+}
+
+public int execute() throws java.io.IOException {
int pkgCnt = 0;
boolean pkgExists = buffer.doesPackageExist();
while ( pkgExists ) {
@@ -114,10 +119,6 @@
pkgExists = buffer.doesPackageExist();
}//end if
return pkgCnt;
-}
-
-public int execute() throws java.io.IOException {
-return append(new byte[0],0,0);
}
public int write(ByteBuffer buf)
1.5 +66 -24
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/io/XByteBuffer.java
Index: XByteBuffer.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/io/XByteBuffer.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- XByteBuffer.java 20 Dec 2003 00:48:52 - 1.4
+++ XByteBuffer.java 9 Jan 2004 23:24:08 - 1.5
@@ -180,24 +180,35 @@
* within the buffer
* @return - true if a complete package (header,size,data,footer) exists within
the buffer
*/
-protected int packageExists()
+public int countPackages()
{
+int cnt = 0;
int pos = START_DATA.length;
-//first check start header
-int index = this.firstIndexOf(buf,0,START_DATA);
-//if the header (START_DATA) isn't the first thing or
-//the buffer isn't even 10 bytes
-if ( index != 0 || (bufSize10) ) return 0;
-//then get the size 4 bytes
-int size = toInt(buf,pos);
-//now the total buffer has to be long enough to hold
-//START_DATA.length+4+size+END_DATA.length
-pos = START_DATA.length+4+size;
-if ( (pos+END_DATA.length) bufSize ) return 0;
-//and finally check the footer of the package END_DATA
-int newpos = firstIndexOf(buf,pos,END_DATA);
-if ( newpos != pos ) return 0;
-return size;
+int start = 0;
+
+while ( start bufSize ) {
+//first check start header
+int index = this.firstIndexOf(buf,start,START_DATA);
+//if the header (START_DATA) isn't the first thing or
+//the buffer isn't even 10 bytes
+if ( index != start || ((bufSize-start)10) ) break;
+//then get the size 4 bytes
+int size = toInt(buf, pos);
+//now the total buffer has to be long enough to hold
+//START_DATA.length+4+size+END_DATA.length
+pos = start + START_DATA.length + 4 + size;
+if ( (pos + END_DATA.length) bufSize) break;
+//and finally check the footer of the package END_DATA
+int newpos = firstIndexOf(buf, pos, END_DATA);
+//mismatch, there is no package
+if (newpos != pos) break;
+//increase the packet count
+cnt++;
+//reset the values
+start = pos + END_DATA.length;
+pos = start + START_DATA.length;
+}//while
+return cnt;
}//getSize
/**
@@ -205,7 +216,7 @@
* @return - true if a complete package (header,size,data,footer)
cvs commit: jakarta-tomcat-catalina/catalina/src/conf server.xml
fhanik 2004/01/09 15:28:23 Modified:catalina/src/conf server.xml Log: Added the 'pooled' replication setting. Revision ChangesPath 1.27 +2 -1 jakarta-tomcat-catalina/catalina/src/conf/server.xml Index: server.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/server.xml,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- server.xml25 Nov 2003 19:14:46 - 1.26 +++ server.xml9 Jan 2004 23:28:23 - 1.27 @@ -258,7 +258,8 @@ HashMap map = (HashMap)session.getAttribute(map); map.put(key,value); % - replicationMode = can be either 'synchronous' or 'asynchronous'. + replicationMode = can be either 'pooled', 'synchronous' or 'asynchronous'. + * Pooled means that the replication happens using several sockets in a synchronous way. Ie, the data gets replicated, then the request return. This is the same as the 'synchronous' setting except it uses a pool of sockets, hence it is multithreaded. This is the fastest and safest configuration. To use this, also increase the nr of tcp threads that you have dealing with replication. * Synchronous means that the thread that executes the request, is also the thread the replicates the data to the other nodes, and will not return until all nodes have received the information. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs cluster-howto.xml
fhanik 2004/01/09 15:36:34 Modified:catalina/src/conf server.xml webapps/docs cluster-howto.xml Log: Set the default replication mode to be pooled, for faster performance Revision ChangesPath 1.28 +3 -2 jakarta-tomcat-catalina/catalina/src/conf/server.xml Index: server.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/server.xml,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- server.xml9 Jan 2004 23:28:23 - 1.27 +++ server.xml9 Jan 2004 23:36:33 - 1.28 @@ -283,15 +283,16 @@ mcastPort=45564 mcastFrequency=500 mcastDropTime=3000 - tcpThreadCount=2 + tcpThreadCount=6 tcpListenAddress=auto tcpListenPort=4001 tcpSelectorTimeout=100 printToScreen=false expireSessionsOnShutdown=false useDirtyFlag=true - replicationMode=synchronous + replicationMode=pooled / + -- !-- When configuring for clustering, you also add in a valve to catch all the requests 1.4 +11 -5 jakarta-tomcat-catalina/webapps/docs/cluster-howto.xml Index: cluster-howto.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/cluster-howto.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- cluster-howto.xml 22 Dec 2003 15:18:24 - 1.3 +++ cluster-howto.xml 9 Jan 2004 23:36:34 - 1.4 @@ -234,7 +234,6 @@ p The membership is established by all the tomcat instances are sending broadcast messages on the same multicast IP and port. - The TCP listen port, is the port where the session replication is received from other members. /p p @@ -242,18 +241,25 @@ replication. /p p -One of the most important performance considerations is the synchronous versus asynchronous replication +One of the most important performance considerations is the synchronous (pooled or not pooled) versus asynchronous replication mode. In a synchronous replication mode the request doesn't return until the replicated session has been sent over the wire and reinstantiated on all the other cluster nodes. -Using synchronous mode potentially becomes a bottleneck, but is a must if you cant have -sticky sessions, what is recommended here is to increase the number of threads that handle +There are two settings for synchronous replication. Pooled or not pooled. +Not pooled (ie replicationMode=quot;synchronousquot;) means that all the replication request are sent over a single +socket. +Using synchronous mode potentially becomes a bottleneck, +You can overcome this bottleneck by setting replicationMode=quot;pooledquot;. +What is recommended here is to increase the number of threads that handle incoming replication request. This is the tcpThreadCount property in the cluster -section of server.xml. +section of server.xml. The pooled setting means that we are using multiple sockets, hence increases the performance. Asynchronous replication, should be used if you have sticky sessions until fail over, then your replicated data is not time crucial, but the request time is, at this time leave the tcpThreadCount to be number-of-nodes-1. During async replication, the request is returned before the data has been replicated. async replication yields shorter request times, and synchronous replication guarantees the session to be replicated before the request returns. +/p +p +The parameter quot;replicationModequot; has three different settings: quot;pooledquot;, quot;synchronousquot; and quot;asynchronousquot; /p /section - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12214] - No reading of newly created .properties files.
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=12214. 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=12214 No reading of newly created .properties files. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2004-01-09 23:41 --- This works for me. If you re-open this bug, please provide more information regarding error you see and the steps to reproduce it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14113] - HTML special characters not escaped in error page output
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=14113. 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=14113 HTML special characters not escaped in error page output [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-01-10 00:14 --- *** This bug has been marked as a duplicate of 9625 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26034] New: - Statefull session bean load failure
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=26034. 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=26034 Statefull session bean load failure Summary: Statefull session bean load failure Product: Tomcat 5 Version: 5.0.16 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This bug already appeared and was fixed in Tomcat 4, see bug# 502. The same web application works fine with the Tomcat 4, which is shipped with JBoss 3.2.2 buf turns out as a real showstopper in Tomcat 5. noisyxp.StudentFacade is a statefull session bean, compiled for J2RE 1.4. The web application works fine up to the point, where this particular class is being loaded. Resolving the home interface of the bean works, but anything beyond (create) fails with the exception below. After printing the exception, the server is highly likely to fall in an endless loop, going unresponsive and creating a multi-megabyte logfile of repetitive stacktraces. 10.01.2004 02:59:56 org.apache.catalina.session.StandardManager doLoad SCHWERWIEGEND: ClassNotFoundException while loading persisted sessions: java.lang.ClassNotFoundException: noisyxp.StudentFacade java.lang.ClassNotFoundException: noisyxp.StudentFacade at org.apache.catalina.loader.StandardClassLoader.loadClass (StandardClassLoader.java:891) at org.apache.catalina.loader.StandardClassLoader.loadClass (StandardClassLoader.java:756) at java.lang.ClassLoader.loadClassInternal(Unknown Source) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Unknown Source) at java.io.ObjectInputStream.resolveProxyClass(Unknown Source) at java.io.ObjectInputStream.readProxyDesc(Unknown Source) at java.io.ObjectInputStream.readClassDesc(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at org.apache.catalina.session.StandardSession.readObject (StandardSession.java:1401) at org.apache.catalina.session.StandardSession.readObjectData (StandardSession.java:895) at org.apache.catalina.session.StandardManager.doLoad (StandardManager.java:450) at org.apache.catalina.session.StandardManager.load (StandardManager.java:377) at org.apache.catalina.session.StandardManager.start (StandardManager.java:690) at org.apache.catalina.core.ContainerBase.setManager (ContainerBase.java:542) at org.apache.catalina.startup.ContextConfig.managerConfig (ContextConfig.java:350) at org.apache.catalina.startup.ContextConfig.start (ContextConfig.java:655) at org.apache.catalina.startup.ContextConfig.lifecycleEvent (ContextConfig.java:254) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent (LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start (StandardContext.java:4212) at org.apache.catalina.core.ContainerBase.addChildInternal (ContainerBase.java:866) at org.apache.catalina.core.ContainerBase.addChild (ContainerBase.java:850) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633) at org.apache.catalina.core.StandardHostDeployer.install (StandardHostDeployer.java:316) at org.apache.catalina.core.StandardHost.install(StandardHost.java:859) at org.apache.catalina.startup.HostConfig.deployWARs (HostConfig.java:653) at org.apache.catalina.startup.HostConfig.deployApps (HostConfig.java:472) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1002) at org.apache.catalina.startup.HostConfig.lifecycleEvent (HostConfig.java:393) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent (LifecycleSupport.java:166) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1133) at org.apache.catalina.core.StandardHost.start(StandardHost.java:816) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1125) at org.apache.catalina.core.StandardEngine.start (StandardEngine.java:518) at org.apache.catalina.core.StandardService.start (StandardService.java:519) at org.apache.catalina.core.StandardServer.start (StandardServer.java:2343) at org.apache.catalina.startup.Catalina.start(Catalina.java:581) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at
