Re: /META-INF/context.xml seemingly ignored
On Aug 3, 2013, at 6:05 PM, Christopher Schultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Nick, > > On 8/3/13 2:54 PM, Nick Williams wrote: >> I'm using Tomcat 8.0.0-RC1. Hopefully I'm just missing something >> here. I created a web application with the following >> /META-INF/context.xml file (I tried both with and without the >> path="/support" attribute). >> >> >> >> > loaderClass="org.springframework.instrument.classloading.tomcat.TomcatInstrumentableClassLoader"/> >> >> > > > If you are using META-INF/context.xml, then the "path" attribute is > definitely illegal/ignored. > > I haven't read the Javadoc for Tomcat 8 yet, but I think you want: > > > > Instead of "loaderClass". At least, that's what it would have been for > Tomcat 7. className is for specified a different Loader implementation. loaderClass is for specifying a different ClassLoader. It's very confusing, but this is definitely right. > >> The JAR containing the TomcatInstrumentableClassLoader is in >> TOMCAT_HOME/lib. However, when the application starts the class >> loader is still Tomcat's WebappClassLoader. >> >> So, I moved the element to TOMCAT_HOME/conf/context.xml >> and now it works. When the application starts the class loader is >> the TomcatInstrumentableClassLoader. > > That's odd. > >> Note that I have confirmed the context.xml file IS in META-INF at >> the root of my web application (not in /WEB-INF/classes/META-INF). >> I also noticed that TOMCAT_HOME/conf/Catalina/localhost is empty. >> There are no files or other directories in that directory at all. >> So, it would appear that my context.xml is not getting copied. I >> don't know whether or not that matters. I am deploying my >> application as an exploded directory (not a WAR), and it is in an >> external directory (it is not in TOMCAT_HOME/webapps). >> >> Am I doing something wrong here, or is this a bug? > > Anything in the "work" directory? CATALINA_BASE/conf/[Engine]/[Host]/ > should be where context.xml files are copied, so .. this definitely > looks fishy. Yes. There's a TOMCAT_HOME/work/Catalina/localhost/support directory, but TOMCAT_HOME/conf/Catalina is empty. Nick - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Probe]- Tomcat deployment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jose, On 8/3/13 5:56 AM, Jose María Zaragoza wrote: > http://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html More like: http://tomcat.apache.org/tomcat-7.0-doc/config/cluster-deployer.html IIRC, this is not a widely-used component... YMMV. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJR/Y02AAoJEBzwKT+lPKRYqGoP/Rh4jcbYiJfpvYvPcRpWzAgf oTeA/GrH8vn6k1/pNnUX/o8fxSkBacSYA0UsTHGEUax2LN0blJlX/5BqaB7MVzhW sLwb1UIedEublNS2CC3gWRo+MwUy3bMZRMjknPmjJUhQRnnGKuoGPDdjfLGOW2mw OiIGPFWtJd6GDn0YztOhPaavDIDtcukRH5+BRF5LOq1iPJKZwXUma1MI0hAtyRuX uPi32PLc9ZqqNNy/56mGQ40Zxd2J7bTAT1vPzDZLvHJg8uEc/5zMKDniLI3gacwq cJr9fzo+UF3g0seiasCBFOhbbXTb+R9aDAKnGz8/XpfYEwpFs49WspLVkmnrOxQj TlT9bWzlWvmj0qt8+YNRPOplFg9tLHvU+ay4ldiC3/T8RLPOnUvFpGbAAEMoqXeR fL2OaOnGRQWZbky6ZU8yUyJLYybzMy9ZtMlla4AhwCWjYHFcrAN+dhPMdaDeC/1z QDiiO4BQwFA5C91hl637Fy+EXLZx28id6GlP5t+b1ak8+4qpAUU1HrkwFAlfSvhr DmEPYQHQSLWG+k8fKaozq9DhrdCA0cYVuiR8viDL7XhhQykPdriSYHFiT+oLDP2G E7z3dD+R0yu+wLE/UWll6vDMr8GMGEw+8jbhFqhBbintsThKnkiZLjGNzxZlTEPS mxpDDhi9aJJLaL8BsnWX =zgmK -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: /META-INF/context.xml seemingly ignored
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 8/3/13 2:54 PM, Nick Williams wrote: > I'm using Tomcat 8.0.0-RC1. Hopefully I'm just missing something > here. I created a web application with the following > /META-INF/context.xml file (I tried both with and without the > path="/support" attribute). > > > > loaderClass="org.springframework.instrument.classloading.tomcat.TomcatInstrumentableClassLoader"/> > > If you are using META-INF/context.xml, then the "path" attribute is definitely illegal/ignored. I haven't read the Javadoc for Tomcat 8 yet, but I think you want: Instead of "loaderClass". At least, that's what it would have been for Tomcat 7. > The JAR containing the TomcatInstrumentableClassLoader is in > TOMCAT_HOME/lib. However, when the application starts the class > loader is still Tomcat's WebappClassLoader. > > So, I moved the element to TOMCAT_HOME/conf/context.xml > and now it works. When the application starts the class loader is > the TomcatInstrumentableClassLoader. That's odd. > Note that I have confirmed the context.xml file IS in META-INF at > the root of my web application (not in /WEB-INF/classes/META-INF). > I also noticed that TOMCAT_HOME/conf/Catalina/localhost is empty. > There are no files or other directories in that directory at all. > So, it would appear that my context.xml is not getting copied. I > don't know whether or not that matters. I am deploying my > application as an exploded directory (not a WAR), and it is in an > external directory (it is not in TOMCAT_HOME/webapps). > > Am I doing something wrong here, or is this a bug? Anything in the "work" directory? CATALINA_BASE/conf/[Engine]/[Host]/ should be where context.xml files are copied, so .. this definitely looks fishy. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJR/Yy0AAoJEBzwKT+lPKRY67AP/0DCd1vlI6A3Et9rYDkstu2e RyukiBRG0H+3JeoJ2SuHVNorjKesJV5LgjwopawXKRuCmkmuds5KV9HFtsrhzWoD PWRFIvGU0RbBKbNisStcBQ5GxafOBKB8uta+HTPukVaOAkjD2jGjp/mE3n4DWfuu xl73Ij/cwHeULSzrF0RRWm/sB508d8ZyVN17L7rwNTxzBVVoIHDybgYKrOEkyK+o 24/0qkbH3ROmRyzayaWQlqBJUQFgfgIgc5kN9HB710kkNNdECSzs8boMMp9yJL5J K2MxHq79D4ZrmlqUQAIaM6bGot4qWfVy8iN/y3+GU/L4nmqtxEz9CEdRuLZ6WrB1 tujz1LFu1noVSHaE1CptiLAR72kTU6qCtsR28TJ0kfYUh9QgOWUpCl8Rs7ity3gH Z5WwZJixHoUVCwSjYTndZEENeIVygNZ8LC6BZKvNS8sAaW3C5Lq0NbO0jBDCgV+G qD78Hu8UUnZR8i0Vm9QpLYlC2FFPLLNNzCbyqJDClp69LcYxrgTnvk9IouNZDjmW Vy7xe379AHnmqpF3ZYda2FwnLNe2wqaS6DhA+eEM6cU0uDhutW8KwjcsPSV1dHwi P7yBINIwlGH3961Knu7lt/PyqpKroBFFr6fSdfGfShLVvla7Z8SZFqCYmZWxolVx zc6AAqu9IicX6qjgooWa =NFNC -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
java.net.SocketException: Connection reset by peer in setSocketOptions()
Dear All, I have an exception that is littering my catalina.out. I see about 7000 of these on a normal day (server handles about 25 requests per second). It is this precise stack trace always. I have some other exceptions, but this one is the main headache I have today. Tomcat 7.0.30 openjdk version "1.7.0_25" FreeBSD 9.1-STABLE My questions: 1) What might be causing this? 2) What other information do you need to help shed some light on this problem? 3) How can I found out if this is happening from specific IP addresses maybe? 4) Any queues that might be overflowing? I have acceptCount 1024 and kern.ipc.somaxconn 1024, which should be plenty, right? 5) Any other steps I can take to dive deeper? Aug 03, 2013 8:50:45 PM org.apache.tomcat.util.net.NioEndpoint setSocketOptions SEVERE: java.net.SocketException: Connection reset by peer at sun.nio.ch.Net.setIntOption0(Native Method) at sun.nio.ch.Net.setSocketOption(Net.java:373) at sun.nio.ch.SocketChannelImpl.setOption(SocketChannelImpl.java:189) at sun.nio.ch.SocketAdaptor.setBooleanOption(SocketAdaptor.java:290) at sun.nio.ch.SocketAdaptor.setTcpNoDelay(SocketAdaptor.java:325) at org.apache.tomcat.util.net.SocketProperties.setProperties(SocketProperties.java:199) at org.apache.tomcat.util.net.NioEndpoint.setSocketOptions(NioEndpoint.java:649) at org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:802) at java.lang.Thread.run(Thread.java:724) -- Kees Jan http://java-monitor.com/ kjkos...@kjkoster.org +31651838192 Repairing cannot be completed, you can only stop doing it. -- Belarusian proverb - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
/META-INF/context.xml seemingly ignored
Guys, I'm using Tomcat 8.0.0-RC1. Hopefully I'm just missing something here. I created a web application with the following /META-INF/context.xml file (I tried both with and without the path="/support" attribute). The JAR containing the TomcatInstrumentableClassLoader is in TOMCAT_HOME/lib. However, when the application starts the class loader is still Tomcat's WebappClassLoader. So, I moved the element to TOMCAT_HOME/conf/context.xml and now it works. When the application starts the class loader is the TomcatInstrumentableClassLoader. Note that I have confirmed the context.xml file IS in META-INF at the root of my web application (not in /WEB-INF/classes/META-INF). I also noticed that TOMCAT_HOME/conf/Catalina/localhost is empty. There are no files or other directories in that directory at all. So, it would appear that my context.xml is not getting copied. I don't know whether or not that matters. I am deploying my application as an exploded directory (not a WAR), and it is in an external directory (it is not in TOMCAT_HOME/webapps). Am I doing something wrong here, or is this a bug? Nick - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: libapr-1.so.0 not deployed for Tomcat 7
On 03.08.2013 06:06, srinivas yelamanchili wrote: > Thanks Chris > > I installed the APR with --prefix=/apps/mstrat/apache/apr-1.4.8 > > The tomcat native configure had this parameter > '--with-apr=/apps/mstrat/apache/apr-1.4.8' > , so if it's building libtcnative i would expected it pick the libapr-1.so.0 > from this apr folder just to be sure > that the libtcnative and libapr in the deployed catalina lib folder are on > the same page. > > I however noted your point (and valid) and will copy the libapr from APR lib > manually to catalina lib In the world of native libraries "--prefix=/apps/mstrat/apache/apr-1.4.8" isn't sufficient to "install". The library needs to be found by the runtime linker. So you have several options: - install it into a system default library path - install it anywhere but configure the runtime linker to look for libs in that place as well - install it anywhere and set the appropriate environment variable to inform the runtime linker about this place (for your platform LD_LIBRARY_PATH). These are all general Unix/Linux things not really special to Tomcat Native. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Help about my problem
On Aug 3, 2013, at 1:55 AM, Mehdi Yousefi wrote: > Hi > Thanks for your attention > it is up on port 8000 > but dident respond > this is for some medical use and the boss did not accept a risk of > updating to last version Well, your boss is wrong and foolish then. Since this is for a medical application of some sort, it is even /more/ imperative that you upgrade. There have been /numerous/ security issues discovered and fixed in Tomcat 6 in the last 6 years. By not upgrading, you are exposing all of that sensitive medical information to those security issues. You are putting your medical application at /greater/ risk by not upgrading. > > my log after startup is > > Aug 2, 2013 9:49:42 PM org.apache.catalina.core.AprLifecycleListener init > INFO: The Apache Tomcat Native library which allows optimal performance in > production environments was not found on the java.library.path: > /usr/java/jdk1.6.0_02/jre/lib/i386/client:/usr/java/jdk1.6.0_02/ > jre/lib/i386:/usr/java/jdk1.6.0_02/jre/../lib/i386:/usr/java/packages/lib/i386:/lib:/usr/lib > Aug 2, 2013 9:49:42 PM org.apache.coyote.http11.Http11Protocol init INFO: > Initializing Coyote HTTP/1.1 on http-80 Aug 2, 2013 9:49:42 PM > org.apache.catalina.startup.Catalina load INFO: Initialization processed in > 266 ms Aug 2, 2013 9:49:42 PM org.apache.tomcat.util.digester.Digester > fatalError SEVERE: Parse Fatal Error at line 1 column 1: Premature end of > file. org.xml.sax.SAXParseException: Premature end of file. at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException > (ErrorHandlerWrapper.java:195) at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError > (ErrorHandlerWrapper.java:174) at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError > (XMLErrorReporter.java:388) at > com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1411) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next > (XMLDocumentScannerImpl.java:1037) at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next > (XMLDocumentScannerImpl.java:645) at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument > (XMLDocumentFragmentScannerImpl.java:508) at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse > (XML11Configuration.java:807) at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse > (XML11Configuration.java:737) at > com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107) > at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse > (AbstractSAXParser.java:1205) at > com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse > (SAXParserImpl.java:522) at > org.apache.tomcat.util.digester.Digester.parse(Digester.java:1581) at > org.apache.catalina.users.MemoryUserDatabase.open(MemoryUserDatabase.java:402) > at org.apache.catalina.users.MemoryUserDatabaseFactory.getObjectInstance > (MemoryUserDatabaseFactory.java:103) at > org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:140) > at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304) > at org.apache.naming.NamingContext.lookup(NamingContext.java:793) at > org.apache.naming.NamingContext.lookup(NamingContext.java:140) at > org.apache.naming.NamingContextBindingsEnumeration.nextElementInternal > (NamingContextBindingsEnumeration.java:113) at > org.apache.naming.NamingContextBindingsEnumeration.next > (NamingContextBindingsEnumeration.java:71) at > org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans > (GlobalResourcesLifecycleListener.java:137) at > org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans > (GlobalResourcesLifecycleListener.java:109) at > org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.lifecycleEvent > (GlobalResourcesLifecycleListener.java:81) at > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120) > at org.apache.catalina.core.StandardServer.start(StandardServer.java:703) > at org.apache.catalina.startup.Catalina.start(Catalina.java:552) at > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) at > org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at > org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) Aug 2, 2013 > 9:49:42 PM org.apache.naming.NamingContext lookup WARNING: Unexpected > exception resolving reference org.xml.sax.SAXParseException: Premature end > of file. at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse > (AbstractSAXParser.java:1231) at > com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse >
Re: javaagent is messing with webapp classpath
Hi again, the problem is that my agent is generated with same classes that are used inside my webapp. My guess is that tomcat is getting lost with the classloader... On Thu, Aug 1, 2013 at 7:53 PM, Alberto SOUZA wrote: > I see... even if i leave my agent empty? Because i did this test and, just > with the presence of agent, tomcat got lost. And the same agent works fine > in GlassFish(3 and 4) and Jboss(7 and 8). Right now, for some reason, my > impression is that the agent is requesting that every class used for my > application should be in agent jar. For example, if i have a > ServletContextListener, tomcat is forcing the agent to have the jar bundled > in the agent's jar. > > regards > > > > On Thu, Aug 1, 2013 at 7:05 PM, Leon Rosenberg > wrote: > >> Hello, >> >> yes, your java agent is probably not well coded :-) >> >> regards >> Leon >> >> >> On Thu, Aug 1, 2013 at 8:33 PM, Alberto SOUZA >> wrote: >> >> > Hi, >> > >> > I have a javaagent that changes some specific classes of my project. >> But, >> > when i start the server using the agent I get a lot of >> > ClassNotFoundException for a lot of classes... Like >> > ServletContextListener. When I don't use the javaagent argument >> everything >> > goes fine. Does anyone have an idea? >> > >> > Thanks!! >> > >> > >
Re: [Probe]- Tomcat deployment
http://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html 2013/8/3 vicky : > Hi Guys, > > Is there a way by which we can handle the tomcat deployment of war files from > a central location via a Web UI screen ? > > I 'm aware of PROBE (http://code.google.com/p/psi-probe/) by which we can do > the deployment from a Web UI screen but for that we need to > individually deploy the Probe.war across all instances . > > Is there a way out by which we can handle the tomcat deployments from a > central location ( i.e by avoiding deploying probe.war on all instances) > on todifferent physical machines. > > Please suggest & share your valuable thoughts > > > Thanks > Vicky - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[Probe]- Tomcat deployment
Hi Guys, Is there a way by which we can handle the tomcat deployment of war files from a central location via a Web UI screen ? I 'm aware of PROBE (http://code.google.com/p/psi-probe/) by which we can do the deployment from a Web UI screen but for that we need to individually deploy the Probe.war across all instances . Is there a way out by which we can handle the tomcat deployments from a central location ( i.e by avoiding deploying probe.war on all instances) on todifferent physical machines. Please suggest & share your valuable thoughts Thanks Vicky
