Re: Tomcat 6: AJP Connector not started?
Cool. Thanks! On Sat, Dec 18, 2010 at 7:40 PM, Konstantin Kolinko knst.koli...@gmail.comwrote: 2010/12/18 Karel Vervaeke ka...@outerthought.org: I assume that uncommenting the SSL connector breaks things if it isn't configured. Yes, though 6.0.30 will have a fix against this, aka Failure during start of one connector should not leave some connectors started and some ignored https://issues.apache.org/bugzilla/show_bug.cgi?id=49030 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Where does my stderr go?
Hi Chris,
Christopher Schultz wrote on 17.12.2010 18:55:
I can see an stderr file in there. Were you expecting anything to be in
it immediately after startup? Silly question: how are you writing to stderr?
yes, I put some output in one of my servlets, just to test this.
I'm using System.stderr and System.stdout.
BTW: you posted some passwords in your log files. You might want to go
and change those, now, unless it was all some kind of test data.
yup, I know, it's only test data...
I was thinking of your conf/logging.properties file as well as your
configuration for tomcat6w.exe. Describing the log config from
tomcat6w.exe (as you have done) and posting logging.properties should be
enough.
see attachment
Logging set up from tomcat6w:
* Level: Info
* Log path: apache install dir\logs
* Log prefix: jakarta_service_
* Redirect Stdout: auto
* Redirect Stderr: auto
There is a swallowOutput attribute on theContext element (found in
conf/server.xml if you are a bad boy, or in your webapp's
META-INF/context.xml, or in conf/[service]/[host]/[webapp].xml. If set
to true (it defaults to false), then your stdout and stderr will be
redirected to the application's log file which is configured in
conf/logging.properties.
this attribute is not set anywhere.
Thomas
--
Intelligent Communication Software Vertriebs GmbH
Firmensitz: Kistlerhof Str. 111, 81379 München
Registergericht: Amtsgericht München, HRB 88283
Geschäftsführer: Albert Fuss
# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements. See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the License); you may not use this file except in compliance with
# the License. You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an AS IS BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
handlers = 1catalina.org.apache.juli.FileHandler,
2localhost.org.apache.juli.FileHandler, 3manager.org.apache.juli.FileHandler,
4host-manager.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
.handlers = 1catalina.org.apache.juli.FileHandler,
java.util.logging.ConsoleHandler
# Handler specific properties.
# Describes specific configuration info for Handlers.
1catalina.org.apache.juli.FileHandler.level = FINE
1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.FileHandler.prefix = catalina.
2localhost.org.apache.juli.FileHandler.level = FINE
2localhost.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
2localhost.org.apache.juli.FileHandler.prefix = localhost.
3manager.org.apache.juli.FileHandler.level = FINE
3manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
3manager.org.apache.juli.FileHandler.prefix = manager.
4host-manager.org.apache.juli.FileHandler.level = FINE
4host-manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
4host-manager.org.apache.juli.FileHandler.prefix = host-manager.
java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
# Facility specific properties.
# Provides extra control for each logger.
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers =
2localhost.org.apache.juli.FileHandler
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].level
= INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].handlers
= 3manager.org.apache.juli.FileHandler
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].level
= INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].handlers
= 4host-manager.org.apache.juli.FileHandler
# For example, set the com.xyz.foo logger to only log SEVERE
# messages:
#org.apache.catalina.startup.ContextConfig.level = FINE
#org.apache.catalina.startup.HostConfig.level = FINE
#org.apache.catalina.session.ManagerBase.level = FINE
#org.apache.catalina.core.AprLifecycleListener.level=FINE
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: HTTP Status 500 - Server Internal Error (continued!)
I'm not sure the thread Tomcat points out wasn't stopped is related to Commons Logging. Could it be that you created the thread in your app? I think that you are correct here although if I post more of the log for you to see then maybe we can confirm whether it is a common issue or not 20-Dec-2010 08:52:46 org.apache.catalina.startup.Catalina start INFO: Server startup in 8843 ms 20-Dec-2010 08:55:09 org.apache.coyote.http11.Http11AprProtocol pause INFO: Pausing Coyote HTTP/1.1 on http-8080 20-Dec-2010 08:55:09 org.apache.coyote.ajp.AjpAprProtocol pause INFO: Pausing Coyote AJP/1.3 on ajp-8009 20-Dec-2010 08:55:10 org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina 20-Dec-2010 08:55:11 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [Thread-4] but has failed to stop it. This is very likely to create a memory leak. 20-Dec-2010 08:55:11 org.apache.coyote.http11.Http11AprProtocol destroy INFO: Stopping Coyote HTTP/1.1 on http-8080 20-Dec-2010 08:55:11 org.apache.coyote.ajp.AjpAprProtocol destroy INFO: Stopping Coyote AJP/1.3 on ajp-8009 This one? This is about references held by a class in the container classloader to a class in the webapp classloader, which prevents *all* of the webapp classes from being unloaded on undeploy. The problem is not related to Tomcat's complaint about the thread that wasn't stopped. The wiki entry I was referring to was this one (I should have included it in last post). It has a direct link to the one you provided http://wiki.apache.org/commons/Logging/FrequentlyAskedQuestions under subheading (towards the bottom) A memory leak occurs when undeploying/redeploying a webapp that uses Commons Logging. How do I fix this?. This refers to commons-logging-1.0.5.jar, the jar version used within the tika parser plugin in my webapp is version 1.1.1, this is why I am unsure as to how accurate the code is in this wiki entry (although it was last edited on 2010-05-05) actually is. It then goes on to mention that the deployment descriptor for the webapp would need to be updated etc... this is what I was referring to when I mentioned the can of worms. In reading about ClassLoader I have come full circle and have ended up running back into my friend the Endorsed Standards Override Mechanism. I made Jena (which uses its own OWL parser, therefore no need for xerces) available to Tomcat in an endorsed folder, this should override the JAXP API's this seemed to solve the parser problem. If the error I am getting is not related to commons logging, and instead as you mentioned (and as shown in logs) related to the WebappClassLoader then I will pursue this route. Sorry for long post Glasgow Caledonian University is a registered Scottish charity, number SC021474 Winner: Times Higher Education’s Widening Participation Initiative of the Year 2009 and Herald Society’s Education Initiative of the Year 2009 http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6219,en.html
Re: HTTP Status 500 - Server Internal Error (continued!)
Hi Lewis, McGibbney, Lewis John schrieb am 20.12.2010 um 09:42 (+): I'm not sure the thread Tomcat points out wasn't stopped is related to Commons Logging. Could it be that you created the thread in your app? I think that you are correct here although if I post more of the log for you to see then maybe we can confirm whether it is a common issue or not 20-Dec-2010 08:55:11 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [Thread-4] but has failed to stop it. This is very likely to create a memory leak. Well, Thread-4 isn't very informative, is it? You could take a thread dump just before shutting down Tomcat and then check if the unruly thread Tomcat points out is still running is also contained in the thread dump. If so you'll have more information on what causes this issue. In reading about ClassLoader I have come full circle and have ended up running back into my friend the Endorsed Standards Override Mechanism. I made Jena (which uses its own OWL parser, therefore no need for xerces) available to Tomcat in an endorsed folder, this should override the JAXP API's this seemed to solve the parser problem. http://jena.sourceforge.net/ - JAR is 23 MB You should probably place Jena in your webapp's WEB-INF/lib/ folder. This page has information on why to do so: http://wiki.apache.org/commons/Logging/UndeployMemoryLeak Notably: It is therefore a complete mystery to me why people seem so keen to push libraries up out of the components where they belong and into the container's library directories. It's like pushing user code into the operating system kernel. Just don't do it. The endorsed/ folder is not intended to accommodate arbitrary third party libraries. You can read up on what's meant to go there on the Java doc page I posted a link to. For example, the XML parser is. -- Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Occasional (!) error (404) Not Found with Apache Axis 1.4 web service after update to Tomcat 6.0.29
Hi everyone, I have a very strange issue, which only occured after an update from Tomcat 6.0.26 to 6.0.29. I have a number applications doing alltogether ~50-100 SOAP calls per minute to an Apache Axis 1.4 based web service running on Tomcat. After the Tomcat update some of these calls suddenly get a (404)Not Found response from the servlet, with no clear pattern. In a write operation with 20 SOAP calls more or less at once, two may get this response, the rest works well. This has never happened under 6.0.26. I tried to find posts / stuff via Google about this, but there is so much Tomcat newbie stuff with deployment issues that I gave up. I also browsed the changelog. If there is anything already that I overlooked, please direct me to it. Any help highly appreciated! Here some details on my setup: Tomcat 6.0.29 under Windows XP 32bit (other deployments on 2003 server 64bit and Linux, those not tested), vanilla install with service and native selected, no significant config changes after installation (I also diffed to the old V6.0.26 config folder and it is the same). Webapp with Apache Axis 1.4 SOAP library and some custom JSPs (JSPs not involved in the SOAP transactions though, Apache Axis 1.4 is a servlet). Hardware: VMWare virtual server HW version 7, on ESXi 4.1. Nothing helpful in the Tomcat logs afaics. Happy to provide more details, let me know. Thanks for any help! Felix - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
APR and async request
Hi, when I disable APR by removing the tcnative-1.dll or by removing the APR listener from server.xml async requests do not work anymore. I get immediately after the request an empty response body with status 200. I'm using TC 7.0.5 under windows 2003. Thank you. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Occasional (!) error (404) Not Found with Apache Axis 1.4 web service after update to Tomcat 6.0.29
2010/12/20 Felix Dierich f.dier...@overspeed.de: I have a very strange issue, which only occured after an update from Tomcat 6.0.26 to 6.0.29. I have a number applications doing alltogether ~50-100 SOAP calls per minute to an Apache Axis 1.4 based web service running on Tomcat. After the Tomcat update some of these calls suddenly get a (404)Not Found response from the servlet, with no clear pattern. In a write operation with 20 SOAP calls more or less at once, two may get this response, the rest works well. This has never happened under 6.0.26. How is JspServlet configured in your conf/web.xml ? I'd recommend to set its development parameter to the value of false. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Webapp undeploy failure
Hello list, Tried to do a bit of reading on this but the results have not come up. I am using version 6.0.26 on windows XP and all I am trying to do is undeploy (and delete from tomcat webapp folder) one webapp which is deployed every time I start my tomcat instance. Having started my instance I use the following http://localhost:8080/manager/undeploy?path=C:/path/to/webapp, however I got the following error FAIL - Context /wombra is defined in server.xml and may not be undeployed Looking at server.xml I find that 'wombra' is the only webapp specified (I had 2 other apps running, one of which has now been successfully undeployed). In this case this particular webapp was built using Tapestry, is this possibly something to do with why I am getting the undeployment failure? Thank you Lewis Glasgow Caledonian University is a registered Scottish charity, number SC021474 Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009 http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6219,en.html
IS that a good idea moving all the common libs?
Hello, I'm trying to lower the permgen needed by a large amount of webapps moving all the commonly used libs to the tomcat common libs. My questions is: how good is that idea? I read that each *same* lib in WEB-INF/lib is handled as unique, thus requiring additional permgen space. This is the enviroment, if does it matter. Server version: Apache Tomcat/5.5.26 Server number: 5.5.26.0 OS Name:SunOS OS Version: 5.10 Architecture: sparc JVM Version:1.5.0_17-b04 JVM Vendor: Sun Microsystems Inc. Thanks a lot. Bye - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
isapi_redirector.dll Problems - Bad Gateway?
Hi, I am trying to get an application called JIRA to work externally on our corporate domain. We believe we have everything set up properly and have followed numoerous online instructions. The default website in IIS (version 6) is up and the ISAPI filter is loaded with the green light. However, when we go to the website we're getting a Bad Gateway error and the ISAPI logs say this: [Thu Dec 16 11:20:10.559 2010] [1508:1800] [error] ajp_get_reply::jk_ajp_common.c (2058): (worker1) Tomcat is down or refused connection. No response has been sent to the client (yet) [Thu Dec 16 11:20:10.559 2010] [1508:1800] [info] ajp_service::jk_ajp_common.c (2543): (worker1) sending request to tomcat failed (recoverable), because of protocol error (attempt=1) [Thu Dec 16 11:20:10.559 2010] [1508:1800] [debug] ajp_service::jk_ajp_common.c (2400): retry 1, sleeping for 100 ms before retrying [Thu Dec 16 11:20:10.668 2010] [1508:1800] [debug] ajp_send_request::jk_ajp_common.c (1572): (worker1) all endpoints are disconnected. [Thu Dec 16 11:20:10.668 2010] [1508:1800] [debug] jk_open_socket::jk_connect.c (484): socket TCP_NODELAY set to On Could really really use some help here. Please let me know what additional info you need to assist. -- View this message in context: http://old.nabble.com/isapi_redirector.dll-Problems---Bad-Gateway--tp30500400p30500400.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp undeploy failure
On 20/12/2010 17:13, McGibbney, Lewis John wrote: Hello list, Tried to do a bit of reading on this but the results have not come up. I am using version 6.0.26 on windows XP and all I am trying to do is undeploy (and delete from tomcat webapp folder) one webapp which is deployed every time I start my tomcat instance. Having started my instance I use the following http://localhost:8080/manager/undeploy?path=C:/path/to/webapp, however I got the following error FAIL - Context /wombra is defined in server.xml and may not be undeployed Looking at server.xml I find that 'wombra' is the only webapp specified (I had 2 other apps running, one of which has now been successfully undeployed). In this case this particular webapp was built using Tapestry, is this possibly something to do with why I am getting the undeployment failure? Don't define your app in server.xml. p Thank you Lewis Glasgow Caledonian University is a registered Scottish charity, number SC021474 Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009 http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6219,en.html 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: HTTP Status 500 - Server Internal Error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lewis, On 12/18/2010 3:27 PM, McGibbney, Lewis John wrote: This version of Jena comes with Xerces-J 2.6.1, it is installed in webapp's WEB-INF/classes/plugins/lib-xml, will this location present any issue or should I copy it to WEB-INF/lib? Tomcat won't load files from WEB-inf/classes/plugins/lib-xml, so there must be something in Jena that is responsible for class loading. You might want to ask the Jena folks about how that works and how to use Jena in a modern JAXP environment. I tried to remove xercesImpl.jar from the lib-xml folder restart Tomcat but I am still encountering the same sever error. That suggests to me that the Xerces lib above is being ignored. In regards to your second comment, are you stating that the servlet spec will not interefere with the webapp, so my app deployment should run ok? The servlet specification is designed to allow webapps to call the shots where libraries are concerned. Sometimes there are problems with the spec and/or an implementation (like Tomcat) that allow incompatibilities to arise, but most of those have been taken care of by now. XML libraries have been a problem in past versions of Tomcat, but I know that I definitely use Xerces in a webapp and I'm sure that it is incompatible with whatever ships with the JRE given it's age. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0PtnsACgkQ9CaO5/Lv0PCtTwCeN+IzUrFfI/5jZLNm41yvKyZZ EvEAoMQmWFC2i2+az2/swotRqiKRx7XP =WLOB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IS that a good idea moving all the common libs?
On Dec 20, 2010, at 12:16, Luca Gervasi tom...@ashetic.net wrote: I'm trying to lower the permgen needed by a large amount of webapps moving all the commonly used libs to the tomcat common libs. That's a really, really bad idea. You would be intertwining all your webapps, potentially introducing object leaks across webapps, and creating insurmountable versioning issues. You'd also require a complete Tomcat restart to update any single webapp. Webapps are intended to be independent; don't make your life miserable by tying them all together. If you need more PermGen space, configure it. If you've got memory leaks, fix them. - Chuck - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTP Status 500 - Server Internal Error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Micheal, On 12/19/2010 7:35 AM, Michael Ludwig wrote: In the case of Xerces, however, it is preferable to put the JAR(s) into %CATALINA_HOME%\endorsed (which may not exist but may be created) so they will be available to all of Tomcat and outmatch the Sun fork shipping with the JRE. I'm not sure I'd recommend this unless no other option will work: overriding the vendor-supplied XML parser with one that is quite old (as Xerces 2.6.1 appears to be) may open you up to security vulnerabilities as well as other incompatibilities with the library. Always be sure to test thoroughly before going into production. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0PugEACgkQ9CaO5/Lv0PChqACfSBG/O9XOqc7W0/o7s1J97Vmb n30AoKlErx3YPocr8qWX3yeUg/IU4vpN =SG0d -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IS that a good idea moving all the common libs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luca, On 12/20/2010 12:15 PM, Luca Gervasi wrote: I'm trying to lower the permgen needed by a large amount of webapps moving all the commonly used libs to the tomcat common libs. +1 to everything Chuck said. My questions is: how good is that idea? How many classes are we talking about? java.lang.Class objects aren't really that heavy. - -chrids -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0PumEACgkQ9CaO5/Lv0PAYKACeOOGbkG/HpSPQeHPID3b0ZYcD 1aAAoKntTbBN/zBdloPtl/8Ua35HA/HN =jRn6 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Where does my stderr go?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas, On 12/20/2010 3:40 AM, Thomas Kloeber wrote: Hi Chris, Christopher Schultz wrote on 17.12.2010 18:55: I can see an stderr file in there. Were you expecting anything to be in it immediately after startup? Silly question: how are you writing to stderr? yes, I put some output in one of my servlets, just to test this. I'm using System.stderr and System.stdout. No wonder it's not working: System.stdout and System.stderr don't exist as far as I know. Did you mean System.err and System.out? Precision counts, especially when things aren't working the way you expect them to be. I was thinking of your conf/logging.properties file as well as your configuration for tomcat6w.exe. Describing the log config from tomcat6w.exe (as you have done) and posting logging.properties should be enough. see attachment :( Attachments are often stripped from posts to the list. Try just copy-and-pasting inline. Logging set up from tomcat6w: * Level: Info * Log path: apache install dir\logs * Log prefix: jakarta_service_ * Redirect Stdout: auto * Redirect Stderr: auto Someone more familiar with win32 will have to comment on what those settings are expected to produce. Note that the Log* parameters have nothing to do with stdout/stderr: they are for reporting (whatever) to the Windows System Log. The documentation I can find for the --StdOutput and --StdError command-line parameters seem to indicate that they describe a filename. I would expect auto to be the filename. If you haven't specified the path, you will have to check the working directory of the service to determine where that file will try to be written. I'm not sure if Tomcat's service wrapper will fail silently or angrily if files cannot be created. If I were you, I'd specify an exact filename, including full path, for the Redirect Stdout and Redirect Stderr settings, and make sure that the effective user running the Tomcat service (TOMCAT? LOCAL_SERVICE?) has rights to write to that file/directory. There is a swallowOutput attribute on the Context element (found in conf/server.xml if you are a bad boy, or in your webapp's META-INF/context.xml, or in conf/[service]/[host]/[webapp].xml. If set to true (it defaults to false), then your stdout and stderr will be redirected to the application's log file which is configured in conf/logging.properties. this attribute is not set anywhere. Good to know. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0PvMQACgkQ9CaO5/Lv0PBp5ACgkzVO2vLpJMB2Xi1wQMCNthf+ UGIAoJtPahYPMzow29oX8eqdjZnUV0y5 =fvQ1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTP Status 500 - Server Internal Error
Moin Chris, Christopher Schultz schrieb am 20.12.2010 um 15:18 (-0500): On 12/19/2010 7:35 AM, Michael Ludwig wrote: In the case of Xerces, however, it is preferable to put the JAR(s) into %CATALINA_HOME%\endorsed (which may not exist but may be created) so they will be available to all of Tomcat and outmatch the Sun fork shipping with the JRE. I'm not sure I'd recommend this unless no other option will work: overriding the vendor-supplied XML parser with one that is quite old (as Xerces 2.6.1 appears to be) may open you up to security vulnerabilities as well as other incompatibilities with the library. I must have overlooked the ancient Xerces version, and the fact that it is bundled with Jena. I wonder why they're using such an old version? I don't recommend putting that into endorsed/. Thanks for catching this. In general, however, I would prefer Apache Xerces to the Sun fork, especially when using JDK 1.6. I've hit a couple of bugs in the Sun fork, and I'm not the only one. I've already seen so many bugs in the Sun JDK 1.6 Xerces version that I recommend people never to use it for production work […] In fact, at some stage I'd like to get rid of the Parse module: this module holds the Sun fork of the Apache Xerces parser, which is horribly buggy; I'd much rather use the Apache original which is much more reliable […] http://saxonica.blogharbor.com/blog/_archives/2009/6/26/4235816.html Those are harsh comments, but I didn't have to do top-notch development like Michael Kay to run into those bugs myself. -- Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp undeploy failure
Pid schrieb am 20.12.2010 um 19:39 (+): On 20/12/2010 17:13, McGibbney, Lewis John wrote: Looking at server.xml I find that 'wombra' is the only webapp specified […] Don't define your app in server.xml. To understand why, search the list archives for Caldarale and context, and/or read the relevant section in the manual. http://tomcat.apache.org/tomcat-6.0-doc/config/context.html -- Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IS that a good idea moving all the common libs?
Luca Gervasi schrieb am 20.12.2010 um 18:15 (+0100): I'm trying to lower the permgen needed by a large amount of webapps moving all the commonly used libs to the tomcat common libs. My questions is: how good is that idea? I read that each *same* lib in WEB-INF/lib is handled as unique, thus requiring additional permgen space. http://wiki.apache.org/commons/Logging/UndeployMemoryLeak Keep component libs in components Servlet and J2EE containers have a clear purpose: to provide a set of services to *independent* and *isolated* components. That set of services is defined by the servlet and j2ee specifications. These specifications also define a mechanism for components to provide any libraries they depend on -- WEB-INF/lib. It is therefore a complete mystery to me why people seem so keen to push libraries up out of the components where they belong and into the container's library directories. It's like pushing user code into the operating system kernel. Just don't do it. I think the fact that many developers are keen to push libraries up out of the components where they belong is due to conceptions stemming from other environments, or probably even from their deeply entrenched desire to remove redundancy from systems, like avoiding to duplicate code, or striving to normalize tables. I remember those were my motivations before I had accepted that a Java application server has been designed to work differently than I had taken for granted. -- Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
How to put restrictions to mod_jk's log
Hello All, My Environment: RHEL 5.3 Apache 2.2.11 mod_jk 1.2.30 JBoss 5.0.0 GA When my system is highly-loaded, the messeges are printed in mod_jk.log. [mod_jk.log] [Tue Dec 21 11:31:25.958 2010] [4744:3086915888] [warn] map_uri_to_worker_ext::jk_uri_worker_map.c (962): Uri * is invalid. Uri must start with / I don't want to print out the warning messages on mod_jk.log. Would you tell me how to restrict them? PS. I assume the messages are caused by Internal Dummy Connection of Apache by reading access_log. [access_log] ::1 - - [21/Dec/2010:11:31:25 +0900] OPTIONS * HTTP/1.0 200 - Regards, - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat 5.5.20
Hi, I am using Tomcat 5.5.20. I am using JNDIRealm to connect to my LDAP server. Through the bugzilla i got to know that there was connection problem in this version of tomcat with LDAP server, if the server is left idle for some time. Two logins were required by the user to log in. (bug ref- ASF Bugzilla – Bug 33774 ) Can you please tell me in which version this problem was fixed, so that i can upgarde the version of my tomcat to avoid this problem Vikas sharma +919971865381 This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited. Visit us at http://www.polaris.co.in
Re: Where does my stderr go?
Chris,
Christopher Schultz wrote on 20.12.2010 21:29:
No wonder it's not working: System.stdout and System.stderr don't exist
as far as I know. Did you mean System.err and System.out? Precision
counts, especially when things aren't working the way you expect them to be.
you are right. Of course I use System.err and System.out
I was thinking of your conf/logging.properties file as well as your
configuration for tomcat6w.exe. Describing the log config from
tomcat6w.exe (as you have done) and posting logging.properties should be
enough.
see attachment
:( Attachments are often stripped from posts to the list. Try just
copy-and-pasting inline.
my last attachment went through even so I go an error message. This time
I didn't get a message so I would have thought it's ok.
I now put it at the end of the message.
Logging set up from tomcat6w:
* Level: Info
* Log path:apache install dir\logs
* Log prefix: jakarta_service_
* Redirect Stdout: auto
* Redirect Stderr: auto
Someone more familiar with win32 will have to comment on what those
settings are expected to produce. Note that the Log* parameters have
nothing to do with stdout/stderr: they are for reporting (whatever) to
the Windows System Log.
The documentation I can find for the --StdOutput and --StdError
command-line parameters seem to indicate that they describe a filename.
I would expect auto to be the filename. If you haven't specified the
path, you will have to check the working directory of the service to
determine where that file will try to be written.
I'm not sure if Tomcat's service wrapper will fail silently or angrily
if files cannot be created. If I were you, I'd specify an exact
filename, including full path, for the Redirect Stdout and Redirect
Stderr settings, and make sure that the effective user running the
Tomcat service (TOMCAT? LOCAL_SERVICE?) has rights to write to that
file/directory.
this is exactly what I did on a previous suggestion. I replaced the
auto bits with C:\tmp\stderr and C:\tmp\stdout. Tomcat creates the
files and writes into stdout. It also creates stderr but it remains
empty. When I set it to auto the files are created in the standard log
directory with the names stdout_XXX.log and stderr_XXX.log where XXX is
the date the files were created.
So from this behaviour I would say, that these settings are for output
of Tomcat (too).
Thomas
logging.properties:
# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements. See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the License); you may not use this file except in compliance with
# the License. You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an AS IS BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
handlers = 1catalina.org.apache.juli.FileHandler,
2localhost.org.apache.juli.FileHandler,
3manager.org.apache.juli.FileHandler,
4host-manager.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
.handlers = 1catalina.org.apache.juli.FileHandler,
java.util.logging.ConsoleHandler
# Handler specific properties.
# Describes specific configuration info for Handlers.
1catalina.org.apache.juli.FileHandler.level = FINE
1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.FileHandler.prefix = catalina.
2localhost.org.apache.juli.FileHandler.level = FINE
2localhost.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
2localhost.org.apache.juli.FileHandler.prefix = localhost.
3manager.org.apache.juli.FileHandler.level = FINE
3manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
3manager.org.apache.juli.FileHandler.prefix = manager.
4host-manager.org.apache.juli.FileHandler.level = FINE
4host-manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
4host-manager.org.apache.juli.FileHandler.prefix = host-manager.
java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter =
java.util.logging.SimpleFormatter
# Facility specific properties.
# Provides extra control for each logger.
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers =
2localhost.org.apache.juli.FileHandler
