Issue with ajp13 socket after tomcat shutdown
After I manually shutdown tomcat (shutdown.sh) the ajp socket seems to stay open for an extended period of time. If I attempt to restart, I get the following output in catalina.out. The problem is that ajp13 should be listening on 8889, but this port is never released, and for some odd reason, it decides to move up one. If I shutdown again, it will switch the port to 8891. I noticed another thread in the archives that discussed a similar problem, but the solution was for the apr connector. The ports do release after a waiting period, but this isn't helpful during development, and I think it might also be the cause of a few errors with tomcat restarting on it's own. (The site seems unavailable but it's just not listening on the correct port) Any help is appreciated. Thank you. Subject: RE: Re: Re: APR Connector Shutdown Problem From: Fenlason, Josh jfenlason () ptc ! com Date: 2006-01-31 22:45:57 ... I added the following line to tomcat-native.1.1.1/jni/native/src/network.c (added at line 388): apr_socket_opt_set( s, APR_SO_REUSEADDR, 1 ); But I'm still running into the same problem. Feb 24, 2006 9:29:02 AM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: The Apache Portable Runtime which allows optimal performance in production environments was not found on the java.library.path: /usr/local/jdk1.5.0_05/jre/lib/i386/server:/usr/local/jdk1.5.0_05/jre/lib/i386:/usr/local/jdk1.5.0_05/jre/../lib/i386 Feb 24, 2006 9:29:03 AM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 1190 ms Feb 24, 2006 9:29:03 AM org.apache.catalina.core.StandardService start INFO: Starting service Catalina Feb 24, 2006 9:29:03 AM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.5.12 Feb 24, 2006 9:29:03 AM org.apache.catalina.core.StandardHost start INFO: XML validation disabled AbandonedObjectPool is used ([EMAIL PROTECTED]) LogAbandoned: false RemoveAbandoned: true RemoveAbandonedTimeout: 300 Feb 24, 2006 9:29:30 AM org.apache.jk.common.ChannelSocket init INFO: Port busy 8889 java.net.BindException: Address already in use Feb 24, 2006 9:29:30 AM org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:8890 Feb 24, 2006 9:29:30 AM org.apache.jk.server.JkMain start INFO: Jk running ID=1 time=0/170 config=null Feb 24, 2006 9:29:30 AM org.apache.catalina.startup.Catalina start INFO: Server startup in 27445 ms - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issue with ajp13 socket after tomcat shutdown
The problem is the same as I'm running into, but I'm not using APR as you can see by my log trace INFO: The Apache Portable Runtime which allows optimal performance in production environments was not found on the java.library.path: /usr/local/jdk1.5.0_05/jre/lib/i386/server:/usr/local/jdk1.5.0 _05/jre/lib/i386:/usr/local/jdk1.5.0_05/jre/../lib/i386 Fenlason, Josh wrote: Take a look at this thread to fix this problem. http://marc.theaimsgroup.com/?l=tomcat-userm=114062756728076w=2 , Josh. -Original Message- From: Joey Geiger [mailto:[EMAIL PROTECTED] Sent: Friday, February 24, 2006 9:24 AM To: users@tomcat.apache.org Subject: Issue with ajp13 socket after tomcat shutdown After I manually shutdown tomcat (shutdown.sh) the ajp socket seems to stay open for an extended period of time. If I attempt to restart, I get the following output in catalina.out. The problem is that ajp13 should be listening on 8889, but this port is never released, and for some odd reason, it decides to move up one. If I shutdown again, it will switch the port to 8891. I noticed another thread in the archives that discussed a similar problem, but the solution was for the apr connector. The ports do release after a waiting period, but this isn't helpful during development, and I think it might also be the cause of a few errors with tomcat restarting on it's own. (The site seems unavailable but it's just not listening on the correct port) Any help is appreciated. Thank you. Subject: RE: Re: Re: APR Connector Shutdown Problem From: Fenlason, Josh jfenlason () ptc ! com Date: 2006-01-31 22:45:57 ... I added the following line to tomcat-native.1.1.1/jni/native/src/network.c (added at line 388): apr_socket_opt_set( s, APR_SO_REUSEADDR, 1 ); But I'm still running into the same problem. Feb 24, 2006 9:29:02 AM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: The Apache Portable Runtime which allows optimal performance in production environments was not found on the java.library.path: /usr/local/jdk1.5.0_05/jre/lib/i386/server:/usr/local/jdk1.5.0 _05/jre/lib/i386:/usr/local/jdk1.5.0_05/jre/../lib/i386 Feb 24, 2006 9:29:03 AM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 1190 ms Feb 24, 2006 9:29:03 AM org.apache.catalina.core.StandardService start INFO: Starting service Catalina Feb 24, 2006 9:29:03 AM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.5.12 Feb 24, 2006 9:29:03 AM org.apache.catalina.core.StandardHost start INFO: XML validation disabled AbandonedObjectPool is used ([EMAIL PROTECTED]) LogAbandoned: false RemoveAbandoned: true RemoveAbandonedTimeout: 300 Feb 24, 2006 9:29:30 AM org.apache.jk.common.ChannelSocket init INFO: Port busy 8889 java.net.BindException: Address already in use Feb 24, 2006 9:29:30 AM org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:8890 Feb 24, 2006 9:29:30 AM org.apache.jk.server.JkMain start INFO: Jk running ID=1 time=0/170 config=null Feb 24, 2006 9:29:30 AM org.apache.catalina.startup.Catalina start INFO: Server startup in 27445 ms - 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]
RE: Tomcat 5.5.15 Context Reloading issue
Well, I discovered the cause of the bug, and I can now stop it from
happening, but I'm unable to *fix* the problem. The top logging statement
works properly, while the commented one does not.
The NullPointer on the date occurs because a date is not being sent to the
logger when the context is reloaded. The date is sent on a startup. Tomcat
can survive this error during reload. The other error
(NoClassDefFoundError:VectorWriter) is an issue with the line number being
sent to the logger, which causes the reload to completely fail.
log4j.appender.ap.layout.ConversionPattern=%p %t %c - %m%n
#log4j.appender.ap.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n
Log output:
Initial Load:
11:42:20,781 INFO
org.apache.catalina.core.ContainerBase.[Catalina].[hostname.com].[/] -
Loading Spring root WebApplicationContext
Reload:
INFO org.apache.catalina.core.ContainerBase.[Catalina].[hostname.com].[/] -
Loading Spring root WebApplicationContext
-Original Message-
From: Caldarale, Charles R [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 07, 2006 9:15 AM
To: Tomcat Users List
Subject: RE: Tomcat 5.5.15 Context Reloading issue
From: Joey Geiger [mailto:[EMAIL PROTECTED]
Subject: Tomcat 5.5.15 Context Reloading issue
The host is configured as:
Host name=application.com appBase=C:\web\application
unpackWARs=true autoDeploy=true xmlValidation=false
xmlNamespaceAware=false reloadable=true
Context path= docBase= debug=1 reloadable=true
Manager pathname= /
/Host
An empty docBase path is rather odd. The appBase parameter is supposed
to point to the directory under which one or more application
directories or war files are stored; docBase should specify the
directory or war for the given application. Perhaps you should try
setting appBase to C:\web and docBase to application.
I've tried to add log4j 1.2.9 to both the common/lib and
server/lib with no success.
Not at the same time, I hope.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
-
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: Session Expires At Every Request (Tomcat5.0.28/Firefox)
Oddly enough, the banks don't even care about this. US Bank, for example, claims their login on the front page is secure and has you enter your account data into a non https form. After the browser sends the information, it then redirects to a secure(https) link. I wrote them about this, and their response was, we know it's not secure, but we'll compensate you for any losses you may have... Crazy. -Original Message- From: George Sexton [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 15, 2006 3:16 PM To: 'Tomcat Users List' Subject: RE: Session Expires At Every Request (Tomcat5.0.28/Firefox) An even simpler case: Adam visits a banking site. On entering the site he gets a cookie. Mallory snoops the session ID on the data stream. Adam then authenticates to read his account information. The application sets a session attribute (say a bean with the account name and number) on the session. Mallory now enters the secure area of the banking site using the forged session ID. Poof. Mallory is logged in as Adam. Poof. Adam is had and his data is there to be stolen, or wire transferred to another account. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original Message- From: George Sexton [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 15, 2006 2:09 PM To: 'Tomcat Users List' Subject: RE: Session Expires At Every Request (Tomcat5.0.28/Firefox) -Original Message- From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 15, 2006 1:16 PM To: Tomcat Users List Subject: Re: Session Expires At Every Request (Tomcat5.0.28/Firefox) George Sexton wrote: Does the code transparently create a new JSessionID value then? George, you might wanna rethink your comments, they don't shine any light on the issue and they for sure don't state any facts, let me prove you I am right. Below is the headers I tracked with LiveHttpHeaders, as you can see, JSESSIONID remains exactly the same in the browser request when the switch from HTTP to HTTPS happens. And this is an incredibly major trap that lies waiting for every application developer that uses sessions. You see, I have given a great deal of thought about sessions and what should happen when a connection transitions to secure, or from secure to non-secure. Let's take a simple shopping cart app. User Adam visit a site on a non-secure connection and receives a session. He shops and puts something in his cart. Mallory (crypto speak for the person in the middle) monitors Adam's network stream and picks up the jsessionid from the data stream. Adam then goes to the check out screen and starts entering checkout data (name, address, and credit card information). To give ourselves a window, assume that Adam then continues shopping or is just slow, or the credit card processing procedure takes time... Mallory can forge a request using the JSessionID, and go to the checkout pages. Since Mallory has the same session, all of the information entered by Adam is now visible. This is the flaw. This is why sessions should not transition from non-secure to secure, or if they do transition a new ID should be generated and the old session ID invalidated. The session ID is a key into the data store and if the session key has been exposed to the public, then no confidential data should be accessed using that session key. I think this should be submitted as a bug. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - 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]
RE: Tomcat 5.5.15 Context Reloading issue
I've done some further searching, and noticed that tomcat was also dumping information into stdout. There is another log trace that might be helpful if anyone else recognizes the problem. I'm of the belief that this is a bug of some sort, but I don't know who to pass the information along to. Also, I tried adding information into the context docbase, and it had no effect on the problem. I also removed all log4j files that I had added to the configuration. Again, this wasn't happening with tomcat 5.5.12, but started after I began to use 5.5.15. Thanks. log4j:ERROR Error occured while converting date. java.lang.NullPointerException at java.lang.System.arraycopy(Native Method) at java.lang.AbstractStringBuilder.getChars(AbstractStringBuilder.java:331) at java.lang.StringBuffer.getChars(StringBuffer.java:202) at org.apache.log4j.helpers.AbsoluteTimeDateFormat.format(AbsoluteTimeDateForma t.java:117) at java.text.DateFormat.format(DateFormat.java:314) at org.apache.log4j.helpers.PatternParser$DatePatternConverter.convert(PatternP arser.java:444) at org.apache.log4j.helpers.PatternConverter.format(PatternConverter.java:64) at org.apache.log4j.PatternLayout.format(PatternLayout.java:503) at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:301) at org.apache.log4j.WriterAppender.append(WriterAppender.java:159) at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:230) at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(Append erAttachableImpl.java:65) at org.apache.log4j.Category.callAppenders(Category.java:203) at org.apache.log4j.Category.forcedLog(Category.java:388) at org.apache.log4j.Category.log(Category.java:853) at org.apache.commons.logging.impl.Log4JLogger.info(Log4JLogger.java:133) at org.apache.catalina.core.ApplicationContext.log(ApplicationContext.java:638) at org.apache.catalina.core.ApplicationContextFacade.log(ApplicationContextFaca de.java:249) at org.springframework.web.context.ContextLoader.initWebApplicationContext(Cont extLoader.java:176) at org.springframework.web.context.ContextLoaderServlet.init(ContextLoaderServl et.java:83) at javax.servlet.GenericServlet.init(GenericServlet.java:211) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:11 05) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java: 3915) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4176) at org.apache.catalina.core.StandardContext.reload(StandardContext.java:2988) at org.apache.catalina.loader.WebappLoader.backgroundProcess(WebappLoader.java: 403) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java: 1276) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processC hildren(ContainerBase.java:1568) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processC hildren(ContainerBase.java:1577) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processC hildren(ContainerBase.java:1577) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(Cont ainerBase.java:1557) at java.lang.Thread.run(Thread.java:595)
RE: Logging session timeouts
Session Listeners http://pdf.coreservlets.com/CSAJSP-Chapter9.pdf -Original Message- From: David Kerber [mailto:[EMAIL PROTECTED] Sent: Thursday, February 09, 2006 8:38 AM To: Tomcat Users List Subject: Logging session timeouts Is there any way of trapping session timeouts, so I can log them? I am logging when a user logs in and when they explicitly log out, but would like to log when their session times out, if that is possible. TIA! Dave - 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: Logging session timeouts
Ugh, sorry I pasted and mailed the wrong link... The example posted by Tim Lucia is good. I was hoping for something a little simpler to implement into my app for just logging a user timing out Just look at the code and use it as a base and modify what you need. -Original Message- From: Joey Geiger [mailto:[EMAIL PROTECTED] Sent: Thursday, February 09, 2006 8:48 AM To: 'Tomcat Users List' Subject: RE: Logging session timeouts Session Listeners http://pdf.coreservlets.com/CSAJSP-Chapter9.pdf -Original Message- From: David Kerber [mailto:[EMAIL PROTECTED] Sent: Thursday, February 09, 2006 8:38 AM To: Tomcat Users List Subject: Logging session timeouts Is there any way of trapping session timeouts, so I can log them? I am logging when a user logs in and when they explicitly log out, but would like to log when their session times out, if that is possible. TIA! Dave - 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]
RE: Logging session timeouts
Here is the code I use, instead of a filter, I use a listener so I don't
have to worry about setting urls.
This part is in web.xml
listener
listener-classyourpackage.SessionListener/listener-class
/listener
The majority of this code was found online (and I think came from
coreservlets.com)
package yourpackage;
import java.util.Date;
import java.util.Enumeration;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
import javax.servlet.http.HttpSession;
import javax.servlet.http.HttpSessionEvent;
import javax.servlet.http.HttpSessionListener;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
public class SessionListener implements ServletContextListener,
HttpSessionListener{
private static int sessionCount=0;
protected transient final Log logger =
LogFactory.getLog(this.getClass());
public void contextInitialized(ServletContextEvent sce)
{
sce.getServletContext().setAttribute(sessionListener,this);
}
public void contextDestroyed(ServletContextEvent sce)
{
}
public synchronized void sessionCreated(HttpSessionEvent event){
HttpSession session = event.getSession();
// session.setMaxInactiveInterval(60);
synchronized (this) {
sessionCount++;
}
String id = session.getId();
Date now = new Date();
String message = new StringBuffer(New Session created on
).append(
now.toString()).append(\nID:
).append(id).append(\n)
.append(There are now ).append( +
sessionCount).append(
live sessions in the
application.).toString();
this.logger.debug(Created: + message);
session.setAttribute(sessionstarted,new Date());
}
public void sessionDestroyed(HttpSessionEvent event) {
HttpSession session = event.getSession();
String id = session.getId();
synchronized (this) {
sessionCount--;
}
String message = new StringBuffer(Session destroyed
+ \nValue of destroyed session ID is
).append( + id)
.append(\n).append(There are now )
.append( + sessionCount).append(
live sessions in the
application.).toString();
this.logger.debug(Destroyed: + message);
Date d = (Date)session.getAttribute(sessionstarted);
this.logger.debug(Session Length:
+millisecondsToString(System.currentTimeMillis() - d.getTime()));
Enumeration stuff = session.getAttributeNames();
while (stuff.hasMoreElements()) {
String name = (String) stuff.nextElement();
// Object value = session.getAttribute(name);
this.logger.debug(Attribute Name:+name);
}
}
public int getSessionCount() { return sessionCount; }
/**
* Converts time in milliseconds to a codeString/code in the
format Days HH:mm:ss.SSS.
* @param time the time in milliseconds.
* @return a codeString/code representing the time in the format
Days HH:mm:ss.SSS.
*/
public static String millisecondsToString(long time)
{
int milliseconds = (int)(time % 1000);
int seconds = (int)((time/1000) % 60);
int minutes = (int)((time/6) % 60);
int hours = (int)((time/360) % 24);
int days = (int)((time/360)/24);
//hours += days*24;
String millisecondsStr = (milliseconds10 ? 00 :
(milliseconds100 ? 0 : ))+milliseconds;
String secondsStr = (seconds10 ? 0 : )+seconds;
String minutesStr = (minutes10 ? 0 : )+minutes;
String hoursStr = (hours10 ? 0 : )+hours;
return new String(days+ Days
+hoursStr+:+minutesStr+:+secondsStr+.+millisecondsStr);
}
}
-Original Message-
From: David Kerber [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 09, 2006 9:56 AM
To: Tomcat Users List
Subject: Re: Logging session timeouts
I got your code in, and it compiles, but I don't understand how I
configure the url-mapping you refer to. Could you point me to some docs
for that? I looked through the web.xml files (both the server one, and
the one for the app), but couldn't find anything about url-mapping or
filters that seemed to apply to this. It may be there, but I don't know
enough about it to recognize it.
Thanks!
Dave
Tim Lucia wrote:
Below is a filter which keeps track of how many sessions are attached to a
web app. The
RE: Logging session timeouts
While the user can delete the cookie that is associated with the session, the server will consider the session valid until it times out, as the user is unable to end the session manually. If you add in a link/button that says Remove my session from server and then have the application invalidate the session, the listener would still log it the same as if the server did it automatically, but you also now have control over logging that. I might be wrong (a famous saying) but I don't know how effective the Filter version of the system will be, as it needs to be invoked via a request in order to process/expire the session. The listener is able to log sessions as they end, and not require a user to hit the filter first. (If a user goes inactive, the session will expire, and the listener will catch it and log it) -Original Message- From: David Kerber [mailto:[EMAIL PROTECTED] Sent: Thursday, February 09, 2006 11:09 AM To: Tomcat Users List Subject: Re: Logging session timeouts That got me going; thanks! One more question: Is there any way of telling if the session was actively invalidated, or if it timed out? Looking at the docs for HttpSessionBindingEvent, I don't see any differentiation between them. That's not a big deal, but would be nice to have. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Logging session timeouts
Thank you for the clarification. -Original Message- From: Tim Lucia [mailto:[EMAIL PROTECTED] Sent: Thursday, February 09, 2006 11:38 AM To: 'Tomcat Users List' Subject: RE: Logging session timeouts The filter, implementing HttpSessionListener, and binding itself to the session, will be called by Tomcat when the session is invalidated (all bound values which implement HttpSessionListener will have their valueUnbound method called.) So, the filter is effective in that it won't miss any session unbind events as long as the filter captures the creation request as well. If you create the session but the request which does so has not passed through the filter, then it will not know when the session goes away. So in the listener case, you are guaranteed a call from the server any time any session is created. That might be a better approach, depending on your need(s). In my case, the filter does a whole lot more, but I stripped it down before posting it to only show the relevant section. Tim -Original Message- From: Joey Geiger [mailto:[EMAIL PROTECTED] Sent: Thursday, February 09, 2006 12:27 PM To: 'Tomcat Users List' Subject: RE: Logging session timeouts While the user can delete the cookie that is associated with the session, the server will consider the session valid until it times out, as the user is unable to end the session manually. If you add in a link/button that says Remove my session from server and then have the application invalidate the session, the listener would still log it the same as if the server did it automatically, but you also now have control over logging that. I might be wrong (a famous saying) but I don't know how effective the Filter version of the system will be, as it needs to be invoked via a request in order to process/expire the session. The listener is able to log sessions as they end, and not require a user to hit the filter first. (If a user goes inactive, the session will expire, and the listener will catch it and log it) -Original Message- From: David Kerber [mailto:[EMAIL PROTECTED] Sent: Thursday, February 09, 2006 11:09 AM To: Tomcat Users List Subject: Re: Logging session timeouts That got me going; thanks! One more question: Is there any way of telling if the session was actively invalidated, or if it timed out? Looking at the docs for HttpSessionBindingEvent, I don't see any differentiation between them. That's not a big deal, but would be nice to have. Dave - 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]
Tomcat 5.5.15 Context Reloading issue
I've run into an issue with Tomcat 5.5.15 and the Context reloading. When I change a file in my application, I have the context set to automatically restart. This was working fine with 5.5.12, but there seems to be an issue after I upgraded to 5.5.15. The host is configured as: Host name=application.com appBase=C:\web\application unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false reloadable=true Context path= docBase= debug=1 reloadable=true Manager pathname= / /Host I've tried to add log4j 1.2.9 to both the common/lib and server/lib with no success. If I stop the server and restart, it works properly. Any help you can provide would be appreciated. Thank you. My stack trace is: INFO: Illegal access: this web application instance has been stopped already. Could not load org.apache.log4j.spi.VectorWriter. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact. java.lang.IllegalStateException at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.jav a:1238) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.jav a:1198) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at org.apache.log4j.spi.LoggingEvent.init(LoggingEvent.java:154) at org.apache.log4j.Category.forcedLog(Category.java:388) at org.apache.log4j.Category.log(Category.java:853) at org.apache.commons.logging.impl.Log4JLogger.error(Log4JLogger.java:193) at org.apache.catalina.core.ApplicationContext.log(ApplicationContext.java:667) at org.apache.catalina.core.ApplicationContextFacade.log(ApplicationContextFaca de.java:269) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:11 41) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java: 3915) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4176) at org.apache.catalina.core.StandardContext.reload(StandardContext.java:2988) at org.apache.catalina.loader.WebappLoader.backgroundProcess(WebappLoader.java: 403) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java: 1276) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processC hildren(ContainerBase.java:1568) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processC hildren(ContainerBase.java:1577) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processC hildren(ContainerBase.java:1577) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(Cont ainerBase.java:1557) at java.lang.Thread.run(Thread.java:595) Feb 6, 2006 4:04:58 PM org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor processChildren SEVERE: Exception invoking periodic operation: java.lang.NoClassDefFoundError: org/apache/log4j/spi/VectorWriter at org.apache.log4j.spi.LoggingEvent.init(LoggingEvent.java:154) at org.apache.log4j.Category.forcedLog(Category.java:388) at org.apache.log4j.Category.log(Category.java:853) at org.apache.commons.logging.impl.Log4JLogger.error(Log4JLogger.java:193) at org.apache.catalina.core.ApplicationContext.log(ApplicationContext.java:667) at org.apache.catalina.core.ApplicationContextFacade.log(ApplicationContextFaca de.java:269) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:11 41) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java: 3915) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4176) at org.apache.catalina.core.StandardContext.reload(StandardContext.java:2988) at org.apache.catalina.loader.WebappLoader.backgroundProcess(WebappLoader.java: 403) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java: 1276) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processC hildren(ContainerBase.java:1568) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processC hildren(ContainerBase.java:1577) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processC hildren(ContainerBase.java:1577) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(Cont ainerBase.java:1557) at
