xml, jse1.5 and the endorsed directory
Does jse1.5 still require using the endorsed directory to override the built-in parser? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Please help with PermGen OutOfMemory error
After many webapp installs, I get this in my tomcat logs... Exception in thread ContainerBackgroundProcessor[StandardEngine[Catalina]] java.lang.OutOfMemory Error: PermGen space MaxPermSize=128m, but the errors still happen. I understand that this comes from apps not releasing all their resources. How do I track down what part of my app is leaving these resources behind? I'm hoping for pointers to tools/articles/blog entries - anything that'll let me isolate this problem (hopefully to a part of my code that I can actually fix as opposed to third party code I have no control over). thx andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
help needed with UTFDataFormatException
Hello. I have a Tomcat 5.5.8 based web application running an Axis 1.2.0 driven web service. When I run a certain chunk of code doing XSLT transformations, the code fails with There was an error while transforming document - java.io.UTFDataFormatException: Invalid byte 1 of 1-byte UTF-8 sequence. I can run this code outside of Tomcat without any problem (using command-line JUnit tests). However, if I run the code from a JSP page or using my web service, it fails with that error. Xerces and Xalan are definitely the same version (System.out with their respective Version objects shows the same info). I am attaching the XSLT file in question in case anyone can see something I can't. Has anyone seen this problem? I'm not finding much useful information searching the archives (of Tomcat, Axis or googling the web/newsgroups). thx andy ?xml version=1.0 encoding=UTF-8? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xsl:output method=html indent=yes encoding=US-ASCII/ xsl:template match=/content htmlbody xsl:apply-templates/ /body/html /xsl:template xsl:template match=@*|node() xsl:choose xsl:when test=@redlined='yes' R xsl:copy xsl:copy-of select=attribute::node()[not(name()='redlined')]/ xsl:apply-templates/ /xsl:copy xsl:if test=name(.)='td' or name(.)='p' or name(.)='tr' or name(.)='table' or name(.)='img'xsl:text#10;/xsl:text/xsl:if /R /xsl:when xsl:otherwise xsl:copy xsl:copy-of select=@*/ xsl:apply-templates/ /xsl:copy xsl:if test=name(.)='td' or name(.)='p' or name(.)='tr' or name(.)='table'xsl:text#10;/xsl:text/xsl:if /xsl:otherwise /xsl:choose /xsl:template /xsl:stylesheet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
commercial monitoring tools
I'm interested in people's experiences with commerical monitoring tools and Tomcat. I found one called ManageEngine that looks interesting - has anyone used that specifically? Are there open-source tools (e.g. Nagios - which I have no experience with) that can do the job just as well (including and especially an easy to use website for displaying monitoring info)? I'm interesting in coming with something that will let me track Tomcat's performance/behavior such that I can isolate what causes it to occasionally hang-up (no info in the logs) or run out of memory. If anyone has already looked into these things and come up with a decent solution please share. Thank you andy kriger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
5.5.8 release timeframe?
I've read the FAQ regarding 'when it's ready' and I haven't seen anything about this in the mailing list archives, however, I still need to be able to answer this question for my boss. We started up the 5.5 path with .4, which had a bug with POST and basic auth that required upgrading to .7 which has a bug with DataSources not closing connections that is fixed in .8 - can anyone give a timeframe for a 5.5.8 release? A rough scale would be fine - days? weeks? months? Even a guesstimate based on experience with how long previous alpha's took to release would help me ease my boss's concerns. thx andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
authentication sporadically fails?
I have Tomcat 5.5.4 configured with basic authentication through a JNDI named JDBC connection pool. The Resource and Realm are specified in META-INF/context.xml. The resource-ref and security-constraint are specified in WEB-INF/web.xml (releveant parts included at the end of this message). There are 3 users assigned roles in the db (MySQL 4.1.8). Sometimes I am seeing one or more of these users fail to authenticate, even though moments before they were able to authenticate. Usually, 1 of the users can still authenticate but the other 2 cannot (though I have seen all 3 fail). Restarting Tomcat usually fixes the problem (though sometimes several restarts are required). I am using IE, Firefox, Java code making HttpUrlConnections, and Apache Axis code making SOAP requests so I'm pretty sure the issue is with Tomcat and not with the component making the request. To the best of my knowledge, when authentication fails, it is failing on the same Authorization header that was succeeding moments before (from watching the access logs and packet sniffing). The problem is inconsistent but frustrating and important for us to figure out. Has anyone seen this kind of behavior? Does anyone have any suggestions for how I can isolate the problem further? thx --- context.xml --- Resource name=jdbc/mydb auth=Container type=javax.sql.DataSource maxActive=64 maxIdle=16 maxWait=1 driverClassName=com.mysql.jdbc.Driver url=jdbc:mysql://localhost/MYDB username=user password=pass / Realm className=org.apache.catalina.realm.DataSourceRealm localDataSource=true dataSourceName=jdbc/mydb userTable=user userNameCol=name userCredCol=password userRoleTable=role roleNameCol=rolename digest=SHA / --- web.xml --- resource-ref descriptionmy database/description res-ref-namejdbc/mydb/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth /resource-ref security-constraint web-resource-collection web-resource-nameAuthentication/web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-namemyRole/role-name /auth-constraint /security-constraint login-config auth-methodBASIC/auth-method realm-nameMy Realm/realm-name /login-config security-role role-namemyRole/role-name /security-role - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
bizarre authentication problem
I have an Tomcat server on an internal network configured to require basic authentication. This works fine when I use IE or Java code to access a site, but when I try to access the site using Firefox, the user/password is never accepted. I have packet sniffed the GET calls from both IE and Firefox and the Authorization header is the same for both. I can access the Tomcat Manager using basic auth and external sites with auth so it's not entirely broken. Tomcat has maxKeepAliveRequests set to 1 (to deal with a .NET SOAP interop problem) - that's the only oddball config in Tomcat. I realize this is more likely a Firefox problem than a Tomcat one, but I'm wondering if anyone has seen behavior like this. This is the diff between the IE HTTP headers () and the Firefox HTTP headers ()... Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Feedreader; .NET CLR 1.0.3705; .NET CLR 1.1.4322) 7c3,9 Connection: Keep-Alive --- User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
reload log4j.properties on-the-fly?
I am running Tomcat 5.5 with log4j logging (log4j.properties in common/classes). Is it possible to make changes to the log4j properties and have the changes reloaded on-the-fly instead of having to restart Tomcat in order to pick up changes? This would be very useful for those times debug level logging or specific class logging is needed where generally that level of logging is not required. thx andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: reload log4j.properties on-the-fly?
Right - I have logging in WEB-INF/classes that I can reload by reloading the webapp (not a big deal). What I'd like is to be able to reload the Tomcat logging (which uses log4j in common/lib and configured in common/classes) without having to restart Tomcat. It's a bit extreme to restart the server just to change logging levels for an specific situation. On Fri, 21 Jan 2005 12:55:15 -0600, Mike Curwen [EMAIL PROTECTED] wrote: Ah, then it wouldn't work at all. I failed to see you say common/classes. It's probably the preferred option to put it in WEB-INF/classes though (not to mention a log4j.jar file per app in WEB-INF/lib). That way you can independantly control logging for each of your apps, plus your logging config won't interfere with Tomcat's internal logging (which many people experience, when they try to do the common/lib approach). Mike Curwen Product Manager Globally Boundless www.globallyboundless.com 204.885.7733 ext 227 Privacy Compliance: This e-mail message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. Any other distribution, copying or disclosure is strictly prohibited. If you have received this message in error, please notify us immediately by telephone (800) 665-1321 and reply to the sender via e-mail, confirming deletion of the original e-mail and any attachment(s). -Original Message- From: Andy Kriger [mailto:[EMAIL PROTECTED] Sent: Friday, January 21, 2005 12:26 PM To: Mike Curwen Subject: Re: reload log4j.properties on-the-fly? In the first case, since log4j.properties is in the global Tomcat classes dir - would that reload every Context? On Fri, 21 Jan 2005 12:19:48 -0600, Mike Curwen [EMAIL PROTECTED] wrote: There's two approaches. Configure tomcat to reload the context when class changes are made (log4j.properties being in the classes directory, will count as a class being changed, and then the whole context will reload). We do this all the time. Log4j can be used in a manner where config changes are discovered at run-time, though I've never tried it (and you should ask about in on the log4j-user list) Mike Curwen -Original Message- From: Andy Kriger [mailto:[EMAIL PROTECTED] Sent: Friday, January 21, 2005 12:03 PM To: tomcat-user@jakarta.apache.org Subject: reload log4j.properties on-the-fly? I am running Tomcat 5.5 with log4j logging (log4j.properties in common/classes). Is it possible to make changes to the log4j properties and have the changes reloaded on-the-fly instead of having to restart Tomcat in order to pick up changes? This would be very useful for those times debug level logging or specific class logging is needed where generally that level of logging is not required. thx andy - 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: reload log4j.properties on-the-fly?
To clarify - an initialization servlet defined in conf/web.xml will be able to reload the log4j config used by the Tomcat server (remember we're not talking about webapps)? On Fri, 21 Jan 2005 14:18:22 -0500, Derrick Koes [EMAIL PROTECTED] wrote: Use the configureAndWatch method of a configurator in an initialization servlet. -Original Message- From: Andy Kriger [mailto:[EMAIL PROTECTED] Sent: Friday, January 21, 2005 2:06 PM To: tomcat-user@jakarta.apache.org Subject: Re: reload log4j.properties on-the-fly? Right - I have logging in WEB-INF/classes that I can reload by reloading the webapp (not a big deal). What I'd like is to be able to reload the Tomcat logging (which uses log4j in common/lib and configured in common/classes) without having to restart Tomcat. It's a bit extreme to restart the server just to change logging levels for an specific situation. On Fri, 21 Jan 2005 12:55:15 -0600, Mike Curwen [EMAIL PROTECTED] wrote: Ah, then it wouldn't work at all. I failed to see you say common/classes. It's probably the preferred option to put it in WEB-INF/classes though (not to mention a log4j.jar file per app in WEB-INF/lib). That way you can independantly control logging for each of your apps, plus your logging config won't interfere with Tomcat's internal logging (which many people experience, when they try to do the common/lib approach). Mike Curwen Product Manager Globally Boundless www.globallyboundless.com 204.885.7733 ext 227 -- -- Privacy Compliance: This e-mail message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. Any other distribution, copying or disclosure is strictly prohibited. If you have received this message in error, please notify us immediately by telephone (800) 665-1321 and reply to the sender via e-mail, confirming deletion of the original e-mail and any attachment(s). -- -- -Original Message- From: Andy Kriger [mailto:[EMAIL PROTECTED] Sent: Friday, January 21, 2005 12:26 PM To: Mike Curwen Subject: Re: reload log4j.properties on-the-fly? In the first case, since log4j.properties is in the global Tomcat classes dir - would that reload every Context? On Fri, 21 Jan 2005 12:19:48 -0600, Mike Curwen [EMAIL PROTECTED] wrote: There's two approaches. Configure tomcat to reload the context when class changes are made (log4j.properties being in the classes directory, will count as a class being changed, and then the whole context will reload). We do this all the time. Log4j can be used in a manner where config changes are discovered at run-time, though I've never tried it (and you should ask about in on the log4j-user list) Mike Curwen -Original Message- From: Andy Kriger [mailto:[EMAIL PROTECTED] Sent: Friday, January 21, 2005 12:03 PM To: tomcat-user@jakarta.apache.org Subject: reload log4j.properties on-the-fly? I am running Tomcat 5.5 with log4j logging (log4j.properties in common/classes). Is it possible to make changes to the log4j properties and have the changes reloaded on-the-fly instead of having to restart Tomcat in order to pick up changes? This would be very useful for those times debug level logging or specific class logging is needed where generally that level of logging is not required. thx andy - 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]
plus/minus of unpack war?
Can someone inside the Tomcat crew explain the advantages/disadvantages of setting unpackWAR=false in the Host configuration? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: undeploy/deploy
Which ant task do you use to deploy/undeploy wars? What is the url in task?
target name=webapp-undeploy depends=webapp-prepare if=app-deployed
undeploy url=${container.mgr.url}
username=${container.mgr.name}
password=${container.mgr.pass}
path=/${webapp.name}/
/target
target name=webapp-deploy depends=webapp-prepare
deploy url=${container.mgr.url}
username=${container.mgr.name}
password=${container.mgr.pass}
path=/${webapp.name}
war=${webapp.war}/
/target
${container.mgr.url} = http://localhost:8080/manager
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: undeploy/deploy
Since 5.x, you don't really need to undeploy first, adding update=true into deploy task will undeploy your app before deployment.. I added that to my Ant script and removed the dependency on webapp-undeploy. Still works about as often as it doesn't. The WAR file is removed but the directory isn't - deploy runs and fails because the path already exists. This is the Host element in server.xml Host name=localhost appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false.../Host This is the Context element in myWebapp/META-INF/context.xml Context antiJARLocking=true antiResourceLocking=true.../Context Is there any specific logging (Tomcat or system) that I could turn on to see why the directory isn't always removed on undeploy? thx andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
undeploy/deploy problem
I am running Tomcat 5.5.x on Solaris 9.x with Java 1.4.x I use an Ant script to deploy my WAR file to Tomcat - it builds a WAR, undeploys the existing webapp, and deploys the WAR. Usually this works fine. However, often enough to big a major annoyance, it doesn't work - the webapp undeploys (according to the Ant output) but the WAR cannot deploy because the directories have not been deleted. Sometimes, I can fix this by manually deleteing the webapps/webapp, conf/Catalina/localhost/webapp.xml and work/Catalina/localhost/webapp directories, sometimes I cannot (if I refresh the manager list, sometimes the webapp disappears, sometimes not). When that doesn't work, I have to restart Tomcat. Does anyone have any ideas what might be going on here and how I might track down the problem? thx andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
resource-ref question
I'm coming to Tomcat 5.5 from greater experience with Resin. I am setting up a JDBC connection pool. No problems there, I have a META-INF/context.xml file with a Resource element in the Context block. What is strange is that I do not need a resource-ref element in the web.xml; my connection pool works fine without it. I see in the docs on the Context config element that Resource and resource-ref are equivalent so I guess that makes sense. What I wonder about is portability - this is locked into Tomcat's way of doing things. Is there a generic way to define connection pools (or a more generic way since I'm guessing there's always going to be some container-specific config). thx andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
reset Resource with JMX?
I have a webapp that defines a JDBC connection pool resource in META-INF/context.xml. When I made a change to the resource name and restarted the webapp, I found that Tomcat did not pick up the new name - my JSP did not work and JConsole showed the old name for the DataSource. I had to restart Tomcat to effect the change. I'm guessing that though the resource is defined in the webapp, because the connection pool is controlled by Tomcat maybe changes aren't picked up on webapp restart? Though I looked around the JMX beans exposed by JConsole and did not see a way to refresh the Resource there, I figure it doesn't hurt to ask the list if anyone knows if this is possible. thx andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
