Re: Tomcat Server Using 100% CPU
Did you reviewed the localhost_access log file. Which web-application is using tomcat the most ? On Thu, Aug 8, 2019 at 9:53 AM Eric Robinson wrote: > We have a farm of VMs, each running multiple instances of tomcat (up to 80 > instances per server). Everything has been running fine for years, but > recently one server has started nailing the CPU to 100% utilization. > > We have tried: > > > * Different versions of tomcat and JDK > * Doubling the resources to 16 cores and 56 GB RAM > * Moving the VM to different physical server > * Rebuilding the tomcat instances on a brand new VM using Windows > Server 2019 > * Rebuilding the tomcat instances on a brand new VM using Red Hat > Enterprise Linux 7.5 > > Nothing has worked. No matter where we run the tomcats, they drive CPU up > to 100%. Meanwhile the other six servers are still running fine. They all > run the same canned tomcat applications. > > We would appreciate some guidance on getting to the bottom of this problem. > > --Eric > > > Disclaimer : This email and any files transmitted with it are confidential > and intended solely for intended recipients. If you are not the named > addressee you should not disseminate, distribute, copy or alter this email. > Any views or opinions presented in this email are solely those of the > author and might not represent those of Physician Select Management. > Warning: Although Physician Select Management has taken reasonable > precautions to ensure no viruses are present in this email, the company > cannot accept responsibility for any loss or damage arising from the use of > this email or attachments. >
Information on sessionCacheSize !
Hello Team and Tomcat users, I am trying to gather more information and the effect of parameter "sessionCacheSize" in server.xml for a ssl connector. I see this from the documentation "The number of SSL sessions to maintain in the session cache." If i do not add this parameter...my tomcat slows down and all the web access becomes extremly slow within a couple of days. This is because by default "0" size is assigned to this parameter which means unlimited cached sessions. So we added the parameter with the value of sessionCacheSize=1 What is the effect of 10k cached session on tomcat, can the problem reoccur once 10k sessions are cached back. I am planning to modify it to test this with a value of sessionCacheSize=1. How can I test to come to a good value for sessioncachesize. My product is using tomcat 7.0.81 (bio connector) with openjdk1.7.0.161 on Linux RedHat 6. -Thanks Utkarsh
Logging framework !
Hi All, I am using Tomcat 7.0.81 on centos 7.2 and using openjdk 1.7.0.141. The problem I am seeing recently is manager*.log and localhost*.log files are not created. Instead, I see the messages that were to be written into, manager.log are going into Catalina.out. catalina.out and localhost_access.log continue to work like before. May I know how and from where to start debugging this? I have verified logging.properties, there is no issue with it. Any help will be appreciable. -Thanks Dave
Web application jars gets re loaded causing permgen issue !
Hi Users, I am running Tomcat 7.0.77 on a linux server with openJDK 1.7.0.131 I am working on an issue where within 2-3 days Tomcat goes out of memory because of java.lang.OutOfMemoryError: PermGen space . After monitoring permgen via jconsole and checking catalina logs we noticed the information messages Jul 12, 2017 11:27:02 AM org.apache.catalina.startup.HostConfig reload INFO: Reloading context [/abc] Jul 12, 2017 11:27:02 AM org.apache.catalina.core.StandardContext reload INFO: Reloading Context with name [/abc] has started I see web.xml within webapp/abc/WEB-INF has the same time stamp of that of the information message. This makes me deduce that since Tomcat sees the new time stamp on web.xml, it reloads this web-app. I, however, do not see the date/time stamp change on webapp/abc folder. Meaning the web application does not get deployed but it getting reloaded into Tomcat. How can i debug this further i find who is responsible in changing web.xml (If my analysis above is correct). Should adding a stack trace within tomcat code (from where "INFO: Reloading context ") will help? Or if there is another option please share with me. Thanks for your help in advance. -Utkarsh Dave
Re: [ANN] Apache Tomcat 7.0.77 released
Hello Violeta, Thanks for the update. We just picked 7.0.76. Wanted to know if there is an important fix in 7.0.77 version and can users face issue if they chose to be on 7.0.76. Just wanted to know if any particular reason because release time between 76 and 77 is short? -Dave On Mon, Apr 3, 2017 at 9:48 AM, Violeta Georgieva wrote: > The Apache Tomcat team announces the immediate availability of Apache > Tomcat 7.0.77. > > Apache Tomcat is an open source software implementation of the Java > Servlet, JavaServer Pages, Java Expression Language and Java > WebSocket technologies. > > This release contains a number of bug fixes and improvements compared to > version 7.0.76. > > Please refer to the change log for the complete list of changes: > http://tomcat.apache.org/tomcat-7.0-doc/changelog.html > > Downloads: > http://tomcat.apache.org/download-70.cgi > > Migration guides from Apache Tomcat 5.5.x and 6.0.x: > http://tomcat.apache.org/migration.html > > Enjoy > > The Apache Tomcat team >
Re: Ways to identify poorly designed client aplications sending request to Tomcat !
Hi Chris, Thanks for the response. On Fri, Mar 31, 2017 at 10:16 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Utkarsh, > > On 3/30/17 3:34 PM, Utkarsh Dave wrote: > > What makes you say that? > > What makes me say what? > > > Past cases, I saw where implementation or not using the JSESSION > > was making the connection over and over again for multiple > > transactions > > Of course. HTTP is a connectionless protocol, so making many > connections with a single session is appropriate. > > But you are saying that your clients are not re-using sessions and so > you want some suggestions. > > I got your point. Actually i meant both reusing connections and sessions both. But as we do not any symptom here, we will leave this for now. Thanks a lot for calrification on session timeout and using the same session for connections. > > What JVM are you using? We using Orcale JDK 1.7.0.131 > > Okay, that's reasonably recent, though still unsupported. I'd move up > to Java 8 if possible. > Ok. > > > Yes, 58 applications. > > Okay, then the presence of 58 WebappClassLoader objects in memory is > not concerning. > > I don't see any indications of any problems with "poor socket > implementations". > > If you have 58 applications deployed and you are only using 787MiB of > heap, that seems fairly good to me. > > It's not really clear what you're asking for, here. Can you expand a > little bit on what you hope to accomplish? > Yes, i will try to be more clear. So, the thing is my server with tomcat 7, has around 58 application deployed. There are 4-5 tools/applications that sends requests to my server. Suddenly the tomcat on all my test set ups stop responding and GUI/web access was slow and sluggish. I found tomcat memory was less than 100 mb, which is unusual then normal. So I am trying to find what consuming memory in tomcat. As Memory heap dump (i used eclipse memory analyzer tool) didn't helped much. I was wondering what is the reason of tomcat going bad. Or it is just i need to add more memory to heap from 1.2 G to 2.4? I am trying to see if jconsole will be helpful here. Any thoughts on debugging this. I alrady reviewed the localhost_Access logs to see all the requests and there response time and response size. Compared them to a working server. Not much of help yet. > > - -chris > > > On Thu, Mar 30, 2017 at 12:01 PM, Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > > Utkarsh, > > > > On 3/29/17 7:33 PM, Utkarsh Dave wrote: > >>>> Hello all, > >>>> > >>>> My tomcat (7.0.72) hosts several web aplications in the > >>>> server (based in linux 6.8). There are many clients or 3rd > >>>> party applications working as client to my server (having > >>>> tomcat and web applications). There are instances when poorly > >>>> designed client application can affect severly to Tomcat. > >>>> Connections/sessions not being reused or closed is one of > >>>> them. > > > > If you have too many sessions, you have two options: > > > > 1. Lower the session-timeout (default: 30min) 2. Identify places in > > the code where sessions are being created but do not need to be > > created > > > >>>> My question is the way to prove/identify such symptoms of the > >>>> 3rd party applications. > >>>> > >>>> I have a situation where all the applications and web/GUI > >>>> access slows down and tomcat shows as consuming 100% cpu > >>>> (even though overall CPU is less) My diagnosis shows memory > >>>> tests for tomcat failing (less than 100KB of free heap left), > >>>> And so i generated memory heap dump and thread dumps. Below > >>>> are the results. Based on below, does this qualify for a > >>>> poorly socket implemetation ? Any thoughts will be helpful. > > > > What makes you say that? > > > >>>> Memory heap dump generated is of Size: 787.3 MB Classes: > >>>> 139k Objects: 19.3m Class Loader: 1.6k > >>>> > >>>> Overview shows 580.9 MB occupied by remainder's. > >>>> > >>>> Problem suspect:- 465 MB occupied by remainder > >>>> > >>>> 152.2 MB- leak suspect 1 6 instances of > >>>> "com.sun.xml.bind.v2.runtime.JAXBContextImpl", loaded by > >>>> "org.apache.catalina.loader.WebappClassLoader @ 0xacc38e98" &g
Re: Ways to identify poorly designed client aplications sending request to Tomcat !
Hi Andre, I suppose we should read 1.2 GB here ? Yes Anyway, why do you say "which is enough" ? How do you know ? By the past test results. that we have been doing on each application And do not top-post. How do we know what you are responding to ? By scrolling up and down ? On Thu, Mar 30, 2017 at 10:43 AM, André Warnier (tomcat) wrote: > On 30.03.2017 19:36, Utkarsh Dave wrote: > >> Thanks Olaf and Suvendu for the response. >> We are using 1.2 MB of heap size which is enough and haven't created an >> issue so far. >> > > I suppose we should read 1.2 GB here ? > Anyway, why do you say "which is enough" ? How do you know ? > And do not top-post. How do we know what you are responding to ? By > scrolling up and down ? > > > > >> On Thu, Mar 30, 2017 at 9:51 AM, Suvendu Sekhar Mondal > > >> wrote: >> >> Memory heap dump generated is of >>>> Size: 787.3 MB Classes: 139k Objects: 19.3m Class Loader: 1.6k >>>> >>> >>> Overview shows 580.9 MB occupied by remainder's. >>>> >>> >>> Problem suspect:- >>>> 465 MB occupied by remainder >>>> >>> >>> Remainder section has retained a good chunk of memory. That indicates >>> lots of small objects are being created by different apps. Your "Live >>> Set" is not very big. What is the heap size? You also mentioned, >>> Tomcat process was consuming high CPU. If you have small heap and all >>> of it is filled up by live objects then JVM will run frequent GC to >>> clean up some space. In that case CPU usage will be high for Tomcat >>> process. >>> >>> As Olaf indicated, you can try to increase heap size and see if the >>> problem goes away. But before that, I am curious to see what heap and >>> GC settings you are using. Please post that info. >>> >>> Thanks! >>> Suvendu >>> >>> On Thu, Mar 30, 2017 at 2:01 PM, Olaf Kock wrote: >>> >>>> Am 30.03.2017 um 01:33 schrieb Utkarsh Dave: >>>> >>>>> Hello all, >>>>> >>>>> My tomcat (7.0.72) hosts several web aplications in the server (based >>>>> in >>>>> linux 6.8). >>>>> >>>> [...] >>>> >>>>> Memory heap dump generated is of >>>>> Size: 787.3 MB Classes: 139k Objects: 19.3m Class Loader: 1.6k >>>>> >>>> The combination of "hosts several web applications" and a heap space of >>>> this size does not convince me of a leak - it might be the memory >>>> requirement of one of the webapps. A leak is typically something that >>>> grows uncontrolled until you run out of heapspace, no matter how much >>>> you grow the available space. >>>> >>>>> In the thread dumps I see these threads repeatedly. I wonder these >>>>> >>>> pointing >>> >>>> to com.rsa.sslj.x. >>>>> >>>> You seem to be handling https requests from Tomcat. If you're not happy >>>> with the implementation of this endpoint/protocol you should move this >>>> to an Apache httpd or similar and just forward to tomcat, so that tomcat >>>> does not deal with encryption. >>>> >>>> As a conclusion: Your problem might not be poorly designed clients, it >>>> might be poorly equipped servers - I'd try to double the memory >>>> allocated to Tomcat's heap and potentially tune the garbage collector. >>>> If you run into problems, you might also identify one of the >>>> webapplications that eats up your resources (no matter what the clients >>>> do). >>>> >>>> Olaf >>>> >>>> - >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>> >>>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >>> >> > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Ways to identify poorly designed client aplications sending request to Tomcat !
Hi Chris What makes you say that? Past cases, I saw where implementation or not using the JSESSION was making the connection over and over again for multiple transactions What JVM are you using? We using Orcale JDK 1.7.0.131 Yes, 58 applications. On Thu, Mar 30, 2017 at 12:01 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Utkarsh, > > On 3/29/17 7:33 PM, Utkarsh Dave wrote: > > Hello all, > > > > My tomcat (7.0.72) hosts several web aplications in the server > > (based in linux 6.8). There are many clients or 3rd party > > applications working as client to my server (having tomcat and web > > applications). There are instances when poorly designed client > > application can affect severly to Tomcat. Connections/sessions not > > being reused or closed is one of them. > > If you have too many sessions, you have two options: > > 1. Lower the session-timeout (default: 30min) > 2. Identify places in the code where sessions are being created but do > not need to be created > > > My question is the way to prove/identify such symptoms of the 3rd > > party applications. > > > > I have a situation where all the applications and web/GUI access > > slows down and tomcat shows as consuming 100% cpu (even though > > overall CPU is less) My diagnosis shows memory tests for tomcat > > failing (less than 100KB of free heap left), And so i generated > > memory heap dump and thread dumps. Below are the results. Based on > > below, does this qualify for a poorly socket implemetation ? Any > > thoughts will be helpful. > > What makes you say that? > > > Memory heap dump generated is of Size: 787.3 MB Classes: 139k > > Objects: 19.3m Class Loader: 1.6k > > > > Overview shows 580.9 MB occupied by remainder's. > > > > Problem suspect:- 465 MB occupied by remainder > > > > 152.2 MB- leak suspect 1 6 instances of > > "com.sun.xml.bind.v2.runtime.JAXBContextImpl", loaded by > > "org.apache.catalina.loader.WebappClassLoader @ 0xacc38e98" occupy > > 159,582,744 (19.33%) bytes. > > It's certainly possible that JAXB and/or your XML-pasring library > could be leaking memory. Older XML parsers would keep the whole XML > document text pinned in memory if some other part of the code grabbed > a single XML attribute and hung-onto the reference. This was actually > fixed in the implementation of String.substring, I believe. > > What JVM are you using? > > > 91 MB- leak suspect 2 58 instances of > > "org.apache.catalina.loader.WebappClassLoader", loaded by > > "java.net.URLClassLoader @ 0xa6b8e038" occupy 95,396,344 (11.56%) > > bytes > > How many applications do you have loaded in the same JVM? If you have > 58, then that's how many WebappClassLoader objects we'd expect to be > present. If you have less than that, you probably have applications > that are not undeploying or reloading cleanly. > > > 79.1 MB - leak suspect 3 4 instances of "com.rsa.sslj.x.aO", loaded > > by "sun.misc.Launcher$ExtClassLoader @ 0xa6b763b0" occupy > > 82,968,424 (10.05%) bytes. > > Is that a 3rd-party JSSE library? > > > In the thread dumps I see these threads repeatedly. I wonder these > > pointing to com.rsa.sslj.x. > > > > "http-bio-8443-exec-230" daemon prio=10 tid=0x1130a400 nid=0x411b > > runnable [0x01be1000] java.lang.Thread.State: RUNNABLE at > > java.net.SocketInputStream.socketRead0(Native Method) at > > java.net.SocketInputStream.read(SocketInputStream.java:153) at > > java.net.SocketInputStream.read(SocketInputStream.java:122) at > > com.rsa.sslj.x.ap.c(Unknown Source) at com.rsa.sslj.x.ap.a(Unknown > > Source) at com.rsa.sslj.x.ap.b(Unknown Source) at > > com.rsa.sslj.x.ap.b(Unknown Source) at > > com.rsa.sslj.x.al.read(Unknown Source) at > > org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer. > java:519) > > > > > at > > org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer. > java:504) > > > > > at > > org.apache.coyote.http11.Http11Processor.setRequestLineReadTimeout(Htt > p11Processor.java:168) > > > > > at > > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp1 > 1Processor.java:998) > > > > > at > > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(A > bstractProtocol.java:637) > > > > > at > > org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint > .java:318) > > &
Re: Ways to identify poorly designed client aplications sending request to Tomcat !
Thanks Olaf and Suvendu for the response. We are using 1.2 MB of heap size which is enough and haven't created an issue so far. On Thu, Mar 30, 2017 at 9:51 AM, Suvendu Sekhar Mondal wrote: > >Memory heap dump generated is of > >Size: 787.3 MB Classes: 139k Objects: 19.3m Class Loader: 1.6k > > >Overview shows 580.9 MB occupied by remainder's. > > >Problem suspect:- > >465 MB occupied by remainder > > Remainder section has retained a good chunk of memory. That indicates > lots of small objects are being created by different apps. Your "Live > Set" is not very big. What is the heap size? You also mentioned, > Tomcat process was consuming high CPU. If you have small heap and all > of it is filled up by live objects then JVM will run frequent GC to > clean up some space. In that case CPU usage will be high for Tomcat > process. > > As Olaf indicated, you can try to increase heap size and see if the > problem goes away. But before that, I am curious to see what heap and > GC settings you are using. Please post that info. > > Thanks! > Suvendu > > On Thu, Mar 30, 2017 at 2:01 PM, Olaf Kock wrote: > > Am 30.03.2017 um 01:33 schrieb Utkarsh Dave: > >> Hello all, > >> > >> My tomcat (7.0.72) hosts several web aplications in the server (based in > >> linux 6.8). > > [...] > >> Memory heap dump generated is of > >> Size: 787.3 MB Classes: 139k Objects: 19.3m Class Loader: 1.6k > > The combination of "hosts several web applications" and a heap space of > > this size does not convince me of a leak - it might be the memory > > requirement of one of the webapps. A leak is typically something that > > grows uncontrolled until you run out of heapspace, no matter how much > > you grow the available space. > >> In the thread dumps I see these threads repeatedly. I wonder these > pointing > >> to com.rsa.sslj.x. > > You seem to be handling https requests from Tomcat. If you're not happy > > with the implementation of this endpoint/protocol you should move this > > to an Apache httpd or similar and just forward to tomcat, so that tomcat > > does not deal with encryption. > > > > As a conclusion: Your problem might not be poorly designed clients, it > > might be poorly equipped servers - I'd try to double the memory > > allocated to Tomcat's heap and potentially tune the garbage collector. > > If you run into problems, you might also identify one of the > > webapplications that eats up your resources (no matter what the clients > > do). > > > > Olaf > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Ways to identify poorly designed client aplications sending request to Tomcat !
Hello all, My tomcat (7.0.72) hosts several web aplications in the server (based in linux 6.8). There are many clients or 3rd party applications working as client to my server (having tomcat and web applications). There are instances when poorly designed client application can affect severly to Tomcat. Connections/sessions not being reused or closed is one of them. My question is the way to prove/identify such symptoms of the 3rd party applications. I have a situation where all the applications and web/GUI access slows down and tomcat shows as consuming 100% cpu (even though overall CPU is less) My diagnosis shows memory tests for tomcat failing (less than 100KB of free heap left), And so i generated memory heap dump and thread dumps. Below are the results. Based on below, does this qualify for a poorly socket implemetation ? Any thoughts will be helpful. Memory heap dump generated is of Size: 787.3 MB Classes: 139k Objects: 19.3m Class Loader: 1.6k Overview shows 580.9 MB occupied by remainder's. Problem suspect:- 465 MB occupied by remainder 152.2 MB- leak suspect 1 6 instances of "com.sun.xml.bind.v2.runtime.JAXBContextImpl", loaded by "org.apache.catalina.loader.WebappClassLoader @ 0xacc38e98" occupy 159,582,744 (19.33%) bytes. 91 MB- leak suspect 2 58 instances of "org.apache.catalina.loader.WebappClassLoader", loaded by "java.net.URLClassLoader @ 0xa6b8e038" occupy 95,396,344 (11.56%) bytes 79.1 MB - leak suspect 3 4 instances of "com.rsa.sslj.x.aO", loaded by "sun.misc.Launcher$ExtClassLoader @ 0xa6b763b0" occupy 82,968,424 (10.05%) bytes. In the thread dumps I see these threads repeatedly. I wonder these pointing to com.rsa.sslj.x. "http-bio-8443-exec-230" daemon prio=10 tid=0x1130a400 nid=0x411b runnable [0x01be1000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:153) at java.net.SocketInputStream.read(SocketInputStream.java:122) at com.rsa.sslj.x.ap.c(Unknown Source) at com.rsa.sslj.x.ap.a(Unknown Source) at com.rsa.sslj.x.ap.b(Unknown Source) at com.rsa.sslj.x.ap.b(Unknown Source) at com.rsa.sslj.x.al.read(Unknown Source) at org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:519) at org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:504) at org.apache.coyote.http11.Http11Processor.setRequestLineReadTimeout(Http11Processor.java:168) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:998) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:318) - locked <0x8f1f68d8> (a org.apache.tomcat.util.net.SocketWrapper) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) "http-bio-8443-exec-232" daemon prio=10 tid=0x11143400 nid=0x411d runnable [0x0943a000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:153) at java.net.SocketInputStream.read(SocketInputStream.java:122) at com.rsa.sslj.x.ap.c(Unknown Source) at com.rsa.sslj.x.ap.a(Unknown Source) at com.rsa.sslj.x.ap.a(Unknown Source) - locked <0x8f52fd38> (a com.rsa.sslj.x.ap) at com.rsa.sslj.x.ap.j(Unknown Source) - locked <0x8f52fd38> (a com.rsa.sslj.x.ap) at com.rsa.sslj.x.ap.i(Unknown Source) - locked <0x8f52fd38> (a com.rsa.sslj.x.ap) at com.rsa.sslj.x.aS.getSession(Unknown Source) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFactory.java:289) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:304) - locked <0x8f53f438> (a org.apache.tomcat.util.net.SocketWrapper) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) -Th
Re: [SECURITY] CVE-2016-6816 Apache Tomcat Information Disclosure
Please ignore my previous mail. I got the correct one https://tomcat.apache.org/security-7.html On Sun, Nov 27, 2016 at 6:41 PM, Utkarsh Dave wrote: > Hi All > > This vulnerability (CVE-2016-6816) is said to be "Affects: 9.0.0.M1 to > 9.0.0.M11" on another url https://tomcat.apache.org/security-9.html. > But in the mail it says Tomcat 7 is also affected. > Does this vulnerability affects version 7.0.72 > > -Regards > Utkarsh > > On Tue, Nov 22, 2016 at 1:42 AM, Mark Thomas wrote: > >> CVE-2016-6816 Apache Tomcat Information Disclosure >> >> Severity: Important >> >> Vendor: The Apache Software Foundation >> >> Versions Affected: >> Apache Tomcat 9.0.0.M1 to 9.0.0.M11 >> Apache Tomcat 8.5.0 to 8.5.6 >> Apache Tomcat 8.0.0.RC1 to 8.0.38 >> Apache Tomcat 7.0.0 to 7.0.72 >> Apache Tomcat 6.0.0 to 6.0.47 >> Earlier, unsupported versions may also be affected. >> >> Description >> The code that parsed the HTTP request line permitted invalid characters. >> This could be exploited, in conjunction with a proxy that also permitted >> the invalid characters but with a different interpretation, to inject >> data into the HTTP response. By manipulating the HTTP response the >> attacker could poison a web-cache, perform an XSS attack and/or obtain >> sensitive information from requests other then their own. >> >> Mitigation >> Users of affected versions should apply one of the following mitigations >> - Upgrade to Apache Tomcat 9.0.0.M13 or later >> (Apache Tomcat 9.0.0.M12 has the fix but was not released) >> - Upgrade to Apache Tomcat 8.5.8 or later >> (Apache Tomcat 8.5.7 has the fix but was not released) >> - Upgrade to Apache Tomcat 8.0.39 or later >> - Upgrade to Apache Tomcat 7.0.73 or later >> - Upgrade to Apache Tomcat 6.0.48 or later >> >> Credit: >> This issue was discovered by Regis Leroy from Makina Corpus. >> >> References: >> [1] http://tomcat.apache.org/security-9.html >> [2] http://tomcat.apache.org/security-8.html >> [3] http://tomcat.apache.org/security-7.html >> [4] http://tomcat.apache.org/security-6.html >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >
Re: [SECURITY] CVE-2016-6816 Apache Tomcat Information Disclosure
Hi All This vulnerability (CVE-2016-6816) is said to be "Affects: 9.0.0.M1 to 9.0.0.M11" on another url https://tomcat.apache.org/security-9.html. But in the mail it says Tomcat 7 is also affected. Does this vulnerability affects version 7.0.72 -Regards Utkarsh On Tue, Nov 22, 2016 at 1:42 AM, Mark Thomas wrote: > CVE-2016-6816 Apache Tomcat Information Disclosure > > Severity: Important > > Vendor: The Apache Software Foundation > > Versions Affected: > Apache Tomcat 9.0.0.M1 to 9.0.0.M11 > Apache Tomcat 8.5.0 to 8.5.6 > Apache Tomcat 8.0.0.RC1 to 8.0.38 > Apache Tomcat 7.0.0 to 7.0.72 > Apache Tomcat 6.0.0 to 6.0.47 > Earlier, unsupported versions may also be affected. > > Description > The code that parsed the HTTP request line permitted invalid characters. > This could be exploited, in conjunction with a proxy that also permitted > the invalid characters but with a different interpretation, to inject > data into the HTTP response. By manipulating the HTTP response the > attacker could poison a web-cache, perform an XSS attack and/or obtain > sensitive information from requests other then their own. > > Mitigation > Users of affected versions should apply one of the following mitigations > - Upgrade to Apache Tomcat 9.0.0.M13 or later > (Apache Tomcat 9.0.0.M12 has the fix but was not released) > - Upgrade to Apache Tomcat 8.5.8 or later > (Apache Tomcat 8.5.7 has the fix but was not released) > - Upgrade to Apache Tomcat 8.0.39 or later > - Upgrade to Apache Tomcat 7.0.73 or later > - Upgrade to Apache Tomcat 6.0.48 or later > > Credit: > This issue was discovered by Regis Leroy from Makina Corpus. > > References: > [1] http://tomcat.apache.org/security-9.html > [2] http://tomcat.apache.org/security-8.html > [3] http://tomcat.apache.org/security-7.html > [4] http://tomcat.apache.org/security-6.html > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: A way for user to specify DH parameter to tomcat !
Thanks a lot Chris and Violeta. On Wed, Aug 17, 2016 at 1:59 PM, Utkarsh Dave wrote: > Hi All, > > My project is using tomcat 7.0.70, JDK 1.7.0_101 and is based on linux OS > We have been using BIO connectors. > 1. I need help to find out how to provide user specified DH parameter to > tomcat. > 2. What all ciphers are categorized under modern ciphers ? > > Thanks for your time in advance. > > -Utkarsh >
Re: A way for user to specify DH parameter to tomcat !
Thanks. By DH I mean "Diffie-Hellman parameters (secure DH-Cipher)". On Wed, Aug 17, 2016 at 3:31 PM, Violeta Georgieva wrote: > Hi, > > 2016-08-17 11:29 GMT+03:00 Utkarsh Dave : > > > > Hi All, > > > > My project is using tomcat 7.0.70, JDK 1.7.0_101 and is based on linux OS > > We have been using BIO connectors. > > 1. I need help to find out how to provide user specified DH parameter to > > tomcat. > > 2. What all ciphers are categorized under modern ciphers ? > > Look at these pages > http://wiki.apache.org/tomcat/Security/Ciphers > http://wiki.apache.org/tomcat/HowTo/SSLCiphers > > Regards, > Violeta > > > > > Thanks for your time in advance. > > > > -Utkarsh >
A way for user to specify DH parameter to tomcat !
Hi All, My project is using tomcat 7.0.70, JDK 1.7.0_101 and is based on linux OS We have been using BIO connectors. 1. I need help to find out how to provide user specified DH parameter to tomcat. 2. What all ciphers are categorized under modern ciphers ? Thanks for your time in advance. -Utkarsh
Re: Can tomcat be configured for ECDHE and DHE cipher suites
Hello Mark, I have a question for SSL Support - BIO and NIO. It is mention that useServerCipherSuitesOrder can be used with Java 8 only So is there a way (in java 7 and BIO and NIO support ) or another parameter we can use with "ciphers" to force client follow the order of ciphers. The JSSE implementation guide documents that the client tells the server which cipher suites it has available, and the server chooses the best mutually acceptable cipher suite. I am facing an issue where TLS_RSA_WITH_AES_256_CBC_SHA is being chosen from all other available ECDHE and DHE suites. -Utkarsh On Fri, May 20, 2016 at 4:51 PM, Mark Thomas wrote: > On 20/05/2016 12:18, Utkarsh Dave wrote: > > Hi Mark - Thanks. > > SSLHonorCipherOrder, cna it be configured on Tomcat ? > > There would not have been much point telling you about a configuration > option you could not use would there? > > It sounds like you need to spend a few minutes looking over the TLS > configuration options for the APR/native HTTP connector: > > > http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#SSL_Support_-_APR/Native > > Mark > > > > > > -thanks > > > > On Fri, May 20, 2016 at 4:42 PM, Mark Thomas wrote: > > > >> On 20/05/2016 12:04, Jan Dosoudil wrote: > >>> Hi, > >>> do you have Java Cryptography Extension (JCE) Unlimited Strength > >>> Jurisdiction Policy Files installed? > >> > >> Irrelevant. The OP is using APR / OpenSSL. > >> > >> The available ciphers are controlled by the SSLCipherSuite which follows > >> the OpenSSL config rules for ciphers. > >> > >> You can set SSLHonorCipherOrder to enforce the server's preference order > >> if you wish. > >> > >> Mark > >> > >> > >>> > >>> JD > >>> > >>> 2016-05-20 12:50 GMT+02:00 Utkarsh Dave : > >>> > >>>> Sorry, I missed that information in my earlier mail. > >>>> Tomcat - 7.0.69 configured for SSL > >>>> Connector - APR > >>>> Java - jdk1.7.0_101 > >>>> > >>>> > >>>> On Fri, May 20, 2016 at 4:10 PM, Mark Thomas > wrote: > >>>> > >>>>> On 20/05/2016 11:37, Utkarsh Dave wrote: > >>>>>> Hi Users and Tomcat team, > >>>>>> > >>>>>> Port 8443 on my product is configured for Tomcat and accepts inbound > >>>>>> traffic from 3rd parties. > >>>>>> In the TLS handshake, Tomcat chooses TLS_RSA_WITH_AES_256_CBC_SHA > over > >>>>> some > >>>>>> of the more secure cipher options offered by the 3rd party. The > >>>>>> 3rd party offers a list of 66 cipher suites that include many > >>>>>> ECDHE and DHE variants. Tomcat configured on my product preferred > >>>> cipher > >>>>>> suite is AES256-SHA. > >>>>>> Can The tomcat be configured for ECDHE and DHE suites must be > >>>>>> available and preferred? > >>>>> > >>>>> Tomcat version? > >>>>> > >>>>> Connector type? > >>>>> > >>>>> Java version? > >>>>> > >>>>> Mark > >>>>> > >>>>> > >>>>> - > >>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >>>>> For additional commands, e-mail: users-h...@tomcat.apache.org > >>>>> > >>>>> > >>>> > >>> > >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Can tomcat be configured for ECDHE and DHE cipher suites
Thanks Mark. It appears it is client (3rd party which requests to tomcta) to choose the cipher while negotiating. We can use SSLHonorCipherOrder to enforce the server's cipher order. I guess i got my answer. -Thanks Utkarsh Dave On Fri, May 20, 2016 at 4:51 PM, Mark Thomas wrote: > On 20/05/2016 12:18, Utkarsh Dave wrote: > > Hi Mark - Thanks. > > SSLHonorCipherOrder, cna it be configured on Tomcat ? > > There would not have been much point telling you about a configuration > option you could not use would there? > > It sounds like you need to spend a few minutes looking over the TLS > configuration options for the APR/native HTTP connector: > > > http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#SSL_Support_-_APR/Native > > Mark > > > > > > -thanks > > > > On Fri, May 20, 2016 at 4:42 PM, Mark Thomas wrote: > > > >> On 20/05/2016 12:04, Jan Dosoudil wrote: > >>> Hi, > >>> do you have Java Cryptography Extension (JCE) Unlimited Strength > >>> Jurisdiction Policy Files installed? > >> > >> Irrelevant. The OP is using APR / OpenSSL. > >> > >> The available ciphers are controlled by the SSLCipherSuite which follows > >> the OpenSSL config rules for ciphers. > >> > >> You can set SSLHonorCipherOrder to enforce the server's preference order > >> if you wish. > >> > >> Mark > >> > >> > >>> > >>> JD > >>> > >>> 2016-05-20 12:50 GMT+02:00 Utkarsh Dave : > >>> > >>>> Sorry, I missed that information in my earlier mail. > >>>> Tomcat - 7.0.69 configured for SSL > >>>> Connector - APR > >>>> Java - jdk1.7.0_101 > >>>> > >>>> > >>>> On Fri, May 20, 2016 at 4:10 PM, Mark Thomas > wrote: > >>>> > >>>>> On 20/05/2016 11:37, Utkarsh Dave wrote: > >>>>>> Hi Users and Tomcat team, > >>>>>> > >>>>>> Port 8443 on my product is configured for Tomcat and accepts inbound > >>>>>> traffic from 3rd parties. > >>>>>> In the TLS handshake, Tomcat chooses TLS_RSA_WITH_AES_256_CBC_SHA > over > >>>>> some > >>>>>> of the more secure cipher options offered by the 3rd party. The > >>>>>> 3rd party offers a list of 66 cipher suites that include many > >>>>>> ECDHE and DHE variants. Tomcat configured on my product preferred > >>>> cipher > >>>>>> suite is AES256-SHA. > >>>>>> Can The tomcat be configured for ECDHE and DHE suites must be > >>>>>> available and preferred? > >>>>> > >>>>> Tomcat version? > >>>>> > >>>>> Connector type? > >>>>> > >>>>> Java version? > >>>>> > >>>>> Mark > >>>>> > >>>>> > >>>>> - > >>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >>>>> For additional commands, e-mail: users-h...@tomcat.apache.org > >>>>> > >>>>> > >>>> > >>> > >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Can tomcat be configured for ECDHE and DHE cipher suites !
Hi Mark - Thanks. SSLHonorCipherOrder, cna it be configured on Tomcat ? -thanks On Fri, May 20, 2016 at 4:42 PM, Mark Thomas wrote: > On 20/05/2016 12:04, Jan Dosoudil wrote: > > Hi, > > do you have Java Cryptography Extension (JCE) Unlimited Strength > > Jurisdiction Policy Files installed? > > Irrelevant. The OP is using APR / OpenSSL. > > The available ciphers are controlled by the SSLCipherSuite which follows > the OpenSSL config rules for ciphers. > > You can set SSLHonorCipherOrder to enforce the server's preference order > if you wish. > > Mark > > > > > > JD > > > > 2016-05-20 12:50 GMT+02:00 Utkarsh Dave : > > > >> Sorry, I missed that information in my earlier mail. > >> Tomcat - 7.0.69 configured for SSL > >> Connector - APR > >> Java - jdk1.7.0_101 > >> > >> > >> On Fri, May 20, 2016 at 4:10 PM, Mark Thomas wrote: > >> > >>> On 20/05/2016 11:37, Utkarsh Dave wrote: > >>>> Hi Users and Tomcat team, > >>>> > >>>> Port 8443 on my product is configured for Tomcat and accepts inbound > >>>> traffic from 3rd parties. > >>>> In the TLS handshake, Tomcat chooses TLS_RSA_WITH_AES_256_CBC_SHA over > >>> some > >>>> of the more secure cipher options offered by the 3rd party. The > >>>> 3rd party offers a list of 66 cipher suites that include many > >>>> ECDHE and DHE variants. Tomcat configured on my product preferred > >> cipher > >>>> suite is AES256-SHA. > >>>> Can The tomcat be configured for ECDHE and DHE suites must be > >>>> available and preferred? > >>> > >>> Tomcat version? > >>> > >>> Connector type? > >>> > >>> Java version? > >>> > >>> Mark > >>> > >>> > >>> - > >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >>> For additional commands, e-mail: users-h...@tomcat.apache.org > >>> > >>> > >> > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Can tomcat be configured for ECDHE and DHE cipher suites !
I have them (US_export_policy.jar and local_policy.jar) under jdk1.7.0_101/jre/lib/security/ On Fri, May 20, 2016 at 4:34 PM, Jan Dosoudil wrote: > Hi, > do you have Java Cryptography Extension (JCE) Unlimited Strength > Jurisdiction Policy Files installed? > > JD > > 2016-05-20 12:50 GMT+02:00 Utkarsh Dave : > > > Sorry, I missed that information in my earlier mail. > > Tomcat - 7.0.69 configured for SSL > > Connector - APR > > Java - jdk1.7.0_101 > > > > > > On Fri, May 20, 2016 at 4:10 PM, Mark Thomas wrote: > > > > > On 20/05/2016 11:37, Utkarsh Dave wrote: > > > > Hi Users and Tomcat team, > > > > > > > > Port 8443 on my product is configured for Tomcat and accepts inbound > > > > traffic from 3rd parties. > > > > In the TLS handshake, Tomcat chooses TLS_RSA_WITH_AES_256_CBC_SHA > over > > > some > > > > of the more secure cipher options offered by the 3rd party. The > > > > 3rd party offers a list of 66 cipher suites that include many > > > > ECDHE and DHE variants. Tomcat configured on my product preferred > > cipher > > > > suite is AES256-SHA. > > > > Can The tomcat be configured for ECDHE and DHE suites must be > > > > available and preferred? > > > > > > Tomcat version? > > > > > > Connector type? > > > > > > Java version? > > > > > > Mark > > > > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > >
Re: Can tomcat be configured for ECDHE and DHE cipher suites !
Sorry, I missed that information in my earlier mail. Tomcat - 7.0.69 configured for SSL Connector - APR Java - jdk1.7.0_101 On Fri, May 20, 2016 at 4:10 PM, Mark Thomas wrote: > On 20/05/2016 11:37, Utkarsh Dave wrote: > > Hi Users and Tomcat team, > > > > Port 8443 on my product is configured for Tomcat and accepts inbound > > traffic from 3rd parties. > > In the TLS handshake, Tomcat chooses TLS_RSA_WITH_AES_256_CBC_SHA over > some > > of the more secure cipher options offered by the 3rd party. The > > 3rd party offers a list of 66 cipher suites that include many > > ECDHE and DHE variants. Tomcat configured on my product preferred cipher > > suite is AES256-SHA. > > Can The tomcat be configured for ECDHE and DHE suites must be > > available and preferred? > > Tomcat version? > > Connector type? > > Java version? > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Can tomcat be configured for ECDHE and DHE cipher suites !
Hi Users and Tomcat team, Port 8443 on my product is configured for Tomcat and accepts inbound traffic from 3rd parties. In the TLS handshake, Tomcat chooses TLS_RSA_WITH_AES_256_CBC_SHA over some of the more secure cipher options offered by the 3rd party. The 3rd party offers a list of 66 cipher suites that include many ECDHE and DHE variants. Tomcat configured on my product preferred cipher suite is AES256-SHA. Can The tomcat be configured for ECDHE and DHE suites must be available and preferred? -Thanks Utkarsh
Re: Some Web Applications fail to deploy !
Correcting the text if it is confusing. "XXX,YYY and ZZZ do not get copied from /usr/local/webapps to Tomcat/webapps after tomcat upgrade as i do not see above logs. And so i feel no installation happens. What can be probable reason On Fri, May 6, 2016 at 11:09 AM, Utkarsh Dave wrote: > Hi Tomcat users and owners, > > I upgraded to tomcat 7.0.69 from 64 and noticed that some of the web > applications do not get deployed. > After verifying i noticed that with tomcat 7.0.64, manager.log file use to > populated with these additional logs where as it is not seen in new Tomcat. > > May 05, 2016 6:26:20 AM org.apache.catalina.core.ApplicationContext log > INFO: Manager: init: Associated with Deployer > 'Catalina:type=Deployer,host=localhost' > .. > INFO: Manager: install: Installing web application 'XXX' from > 'file:/usr/local/webapps/XXX.war' > May 05, 2016 6:28:29 AM org.apache.catalina.core.ApplicationContext log > INFO: Manager: install: Installing web application 'YYY' from > 'file:/usr/local/webapps/YYY.war' > May 05, 2016 6:28:32 AM org.apache.catalina.core.ApplicationContext log > INFO: Manager: install: Installing web application 'ZZZ' from > 'file:/usr/local/webapps/ZZZ.war' > . > XXX,YYY and ZZZ do not get copied from /usr/local/webapps to Tomcat/webapps > Is this some new functionality we put in or I am missing something. > > -Thanks > Utkarsh >
Some Web Applications fail to deploy !
Hi Tomcat users and owners, I upgraded to tomcat 7.0.69 from 64 and noticed that some of the web applications do not get deployed. After verifying i noticed that with tomcat 7.0.64, manager.log file use to populated with these additional logs where as it is not seen in new Tomcat. May 05, 2016 6:26:20 AM org.apache.catalina.core.ApplicationContext log INFO: Manager: init: Associated with Deployer 'Catalina:type=Deployer,host=localhost' .. INFO: Manager: install: Installing web application 'XXX' from 'file:/usr/local/webapps/XXX.war' May 05, 2016 6:28:29 AM org.apache.catalina.core.ApplicationContext log INFO: Manager: install: Installing web application 'YYY' from 'file:/usr/local/webapps/YYY.war' May 05, 2016 6:28:32 AM org.apache.catalina.core.ApplicationContext log INFO: Manager: install: Installing web application 'ZZZ' from 'file:/usr/local/webapps/ZZZ.war' . XXX,YYY and ZZZ do not get copied from /usr/local/webapps to Tomcat/webapps Is this some new functionality we put in or I am missing something. -Thanks Utkarsh
Re: [ANN] Apache Tomcat 7.0.69 released
Thanks again. That helped and all good with compilation now. On Wed, Apr 20, 2016 at 12:50 PM, Violeta Georgieva wrote: > Hi, > > 2016-04-20 10:11 GMT+03:00 Utkarsh Dave : > > > > Hi Violeta, > > I receive a compilation error with new tomcat > > java.lang.NoClassDefFoundError: org/apache/tomcat/util/buf/UriUtil > > > > This class is located in tomcat-coyote.jar file > > Regards, > Violeta > > > When i compared 7.0.69\lib\tomcat-util\org\apache\tomcat\util > > I found buf package and all its classes missing. > > Do i have to add something to my class path to resolve this error > > > > On Tue, Apr 19, 2016 at 11:47 AM, Utkarsh Dave > > wrote: > > > > > Thank You > > > > > > On Mon, Apr 18, 2016 at 5:45 PM, Violeta Georgieva < > violet...@apache.org > > > > > wrote: > > > > > >> The Apache Tomcat team announces the immediate availability of Apache > > >> Tomcat 7.0.69. > > >> > > >> Apache Tomcat is an open source software implementation of the Java > > >> Servlet, JavaServer Pages, Java Expression Language and Java > > >> WebSocket technologies. > > >> > > >> This release contains a number of bug fixes and improvements compared > to > > >> version 7.0.68. The notable changes since 7.0.68 include: > > >> > > >> > > >> - Correct a false positive warning for ThreadLocal related memory > leaks > > >> when the key class but not the value class has been loaded by the > web > > >> application class loader. > > >> > > >> > > >> Please refer to the change log for the complete list of changes: > > >> http://tomcat.apache.org/tomcat-7.0-doc/changelog.html > > >> > > >> Note: This version has 4 zip binaries: a generic one and > > >> three bundled with Tomcat native binaries for Windows > operating > > >> systems running on different CPU architectures. > > >> > > >> Note: Use of the Java WebSocket 1.1 implementation requires Java 7. > > >> > > >> Note: If you use the APR/native AJP or HTTP connector you *must* > upgrade > > >> to version 1.1.33 or later of the APR/native library. > > >> > > >> Downloads: > > >> http://tomcat.apache.org/download-70.cgi > > >> > > >> Migration guides from Apache Tomcat 5.5.x and 6.0.x: > > >> http://tomcat.apache.org/migration.html > > >> > > >> Enjoy > > >> > > >> The Apache Tomcat team > > >> > > > > > > >
Re: [ANN] Apache Tomcat 7.0.69 released
Hi Violeta, I receive a compilation error with new tomcat java.lang.NoClassDefFoundError: org/apache/tomcat/util/buf/UriUtil When i compared 7.0.69\lib\tomcat-util\org\apache\tomcat\util I found buf package and all its classes missing. Do i have to add something to my class path to resolve this error On Tue, Apr 19, 2016 at 11:47 AM, Utkarsh Dave wrote: > Thank You > > On Mon, Apr 18, 2016 at 5:45 PM, Violeta Georgieva > wrote: > >> The Apache Tomcat team announces the immediate availability of Apache >> Tomcat 7.0.69. >> >> Apache Tomcat is an open source software implementation of the Java >> Servlet, JavaServer Pages, Java Expression Language and Java >> WebSocket technologies. >> >> This release contains a number of bug fixes and improvements compared to >> version 7.0.68. The notable changes since 7.0.68 include: >> >> >> - Correct a false positive warning for ThreadLocal related memory leaks >> when the key class but not the value class has been loaded by the web >> application class loader. >> >> >> Please refer to the change log for the complete list of changes: >> http://tomcat.apache.org/tomcat-7.0-doc/changelog.html >> >> Note: This version has 4 zip binaries: a generic one and >> three bundled with Tomcat native binaries for Windows operating >> systems running on different CPU architectures. >> >> Note: Use of the Java WebSocket 1.1 implementation requires Java 7. >> >> Note: If you use the APR/native AJP or HTTP connector you *must* upgrade >> to version 1.1.33 or later of the APR/native library. >> >> Downloads: >> http://tomcat.apache.org/download-70.cgi >> >> Migration guides from Apache Tomcat 5.5.x and 6.0.x: >> http://tomcat.apache.org/migration.html >> >> Enjoy >> >> The Apache Tomcat team >> > >
Re: [ANN] Apache Tomcat 7.0.69 released
Thank You On Mon, Apr 18, 2016 at 5:45 PM, Violeta Georgieva wrote: > The Apache Tomcat team announces the immediate availability of Apache > Tomcat 7.0.69. > > Apache Tomcat is an open source software implementation of the Java > Servlet, JavaServer Pages, Java Expression Language and Java > WebSocket technologies. > > This release contains a number of bug fixes and improvements compared to > version 7.0.68. The notable changes since 7.0.68 include: > > > - Correct a false positive warning for ThreadLocal related memory leaks > when the key class but not the value class has been loaded by the web > application class loader. > > > Please refer to the change log for the complete list of changes: > http://tomcat.apache.org/tomcat-7.0-doc/changelog.html > > Note: This version has 4 zip binaries: a generic one and > three bundled with Tomcat native binaries for Windows operating > systems running on different CPU architectures. > > Note: Use of the Java WebSocket 1.1 implementation requires Java 7. > > Note: If you use the APR/native AJP or HTTP connector you *must* upgrade > to version 1.1.33 or later of the APR/native library. > > Downloads: > http://tomcat.apache.org/download-70.cgi > > Migration guides from Apache Tomcat 5.5.x and 6.0.x: > http://tomcat.apache.org/migration.html > > Enjoy > > The Apache Tomcat team >
When is 7.0.69 expected !
Hi Tomcat team, I am looking for below fix http://svn.apache.org/viewvc?view=revision&revision=1734262 The fix will be available in 7.0.69. Is there a date for the new release yet... -Thanks Utkarsh
Re: response.sendRedirect is not working in application after upgrade from 7.0.65 to 7.0.67
HiVioleta, Our application has a very similar problem after upgrade to tomcat 7.0.67/68 and it seems space in between url attributes was the issue while using response.sendRedirect. Currently we have hold off the upgrade until all web application teams find the affected pages and rectify there code. I heard (above) this will be fixed in 7.0.69 ? Is that the case? and is there an (rough) estimate of the release date/month of 69 release On Thu, Mar 24, 2016 at 12:58 PM, Violeta Georgieva wrote: > 2016-03-24 9:11 GMT+02:00 Palod, Manish : > > > > Hi Violeta, > > We have tried 7.0.68 also, but same issue. > > OK > > We have a fix for something similar > http://svn.apache.org/viewvc?view=revision&revision=1734262 > > The fix will be available in 7.0.69 > Can you build Tomcat 7 trunk and test your scenario? > > Thanks, > Violeta > > > Regards > > Manish > > -Original Message- > > From: Violeta Georgieva [mailto:miles...@gmail.com] > > Sent: Thursday, March 24, 2016 12:36 PM > > To: Tomcat Users List > > Subject: Re: response.sendRedirect is not working in application after > upgrade from 7.0.65 to 7.0.67 > > > > Hi, > > > > 2016-03-24 8:18 GMT+02:00 Palod, Manish : > > > > > > Hello Experts, > > > We are using tomcat in our application from many years and things were > > working fine. > > > > > > After upgrade from tomcat 7.0.65 to 7.0.67, response.sendRedirect is > > > not > > working properly in application. > > > > > > We are having spaces in between url attributes all the time ex. > > companyName=XYZ Inc&Address=ABC Road etc. and didn't face any issues. > > > > > > We are encoding the URL's using "response.encodeURL" before passing > > > url > > param to response.sendRedirect > > > > > > After upgrade to .67, sendRedirect started failing, hence I tried > > changing url encoding using "response.encodeRedirectURL", still > redirection didn't work > > > > > > is this the known issue? > > > is there any work around for this? > > > > > > > Please try 7.0.68 > > This is the last released Tomcat 7 version. > > > > Regards, > > Violeta > > > > > Thanks > > > Manish > > > >
Re: Time zone in all web application pages revert to UTC !
Thanks Chris and John for the response.
Chris - We do not use date formats to display, but we are facing issue like
System.out.println(java.util.TimeZone.getDefault().getID()); //This prints
UTC, which is incorrect
System.out.println(System.getProperty("user.timezone")); //which prints
IST, that is correct
System.out.println(new java.util.Date().toString()); //prints Mon Feb 08
10:42:18 UTC 2016.
After restarting tomcat things get reset.
On one of the blogs I found
setting the default timezone at start time is: java -Duser.timezone=.
I will try this.
But didn't quiet understood that why suddenly when everything works fine,
one odd day the UTC time zone starts displaying.
On Tue, Mar 22, 2016 at 8:25 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> Utkarsh,
>
> On 3/22/16 2:40 AM, Utkarsh Dave wrote:
> > We are having this weird issue seen in all the web application pages
> where
> > time gets changed to UTC after some days.
>
> Aren't you using DateFormats for your date/time printing?
>
> > As a workaround it works fine until Tomcat is restarted, but after some
> > days time in UTC is seen again. This is regardless of any time/time zone
> > configured on the server (IST/PST).
> > We are on linux 6.6 (with ntp running) and use java 1.7.0.95.
> > Need your thoughts on this? Let me know if you need further information
> > If i write a new java class inside tomcat directory and print the output
> to
> > one of the log files and display java.util.TimeZone.getDefault().getID().
> > it will give correct result.
> > Is some attribute within Tomcat or jsp that gets reset ?
>
> Tomcat will not attempt to change the default time zone of the JVM.
>
> How do you print timestamps in your web application? This can easily be
> corrected, but it might be a lot of work if you have been using bad
> practices.
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Time zone in all web application pages revert to UTC !
Hi Users and Tomcat team, We are having this weird issue seen in all the web application pages where time gets changed to UTC after some days. As a workaround it works fine until Tomcat is restarted, but after some days time in UTC is seen again. This is regardless of any time/time zone configured on the server (IST/PST). We are on linux 6.6 (with ntp running) and use java 1.7.0.95. Need your thoughts on this? Let me know if you need further information If i write a new java class inside tomcat directory and print the output to one of the log files and display java.util.TimeZone.getDefault().getID(). it will give correct result. Is some attribute within Tomcat or jsp that gets reset ? -Thanks Utkarsh
Re: Enabling SSLv2 on Tomcat 7 !
Thanks Chris for the response. Yes, I meant SSLv2Hello. I understand the vulnerabilities in SSL. Though some of the client need that flexibility in older versions, so was digging the reason it was working in prior version of Tomcat. Can you help me in identifying any change in Tomcat due to which SSLv2Hello handshake started failing in newer versions of tomcat On Fri, Feb 19, 2016 at 8:56 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Utkarsh, > > On 2/19/16 7:05 AM, Utkarsh Dave wrote: > > I upgraded my tomcat from 7.0.53 ( that was having SSL protocols > > enable) to 7.0.67 (that has by default SSL protocols disable). > > > > To re enable support for SSLv3 and SSLv2, i modified the server.xml > > inside $TOMCAT_HOME/conf to replace sslProtocol="TLS" with > > sslEnabledProtocols="SSLv2,SSLv3,TLSv1" > > > > I can test the SSLv3 requests successfully now , but SSLv2 requests > > still fails. They were processing through success before the > > upgrade of Tomcat. > > > > I am using the JDK1.6 and Redhat platform and openssl version > > 0.9.8h. > > > > Please let me know if i can enable SSLv2 on the newer Tomcat. > > I think you mean "SSLv2Hello", not "SSLv2". > > But please, just let SSL die. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlbHNB8ACgkQ9CaO5/Lv0PDdGQCeILtFaOKuhexXOYDSK7MqNski > 3mIAoLWsujDgusq2eoGDNwrL2B3cQyoY > =NlGV > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Enabling SSLv2 on Tomcat 7 !
I upgraded my tomcat from 7.0.53 ( that was having SSL protocols enable) to 7.0.67 (that has by default SSL protocols disable). To re enable support for SSLv3 and SSLv2, i modified the server.xml inside $TOMCAT_HOME/conf to replace sslProtocol="TLS" with sslEnabledProtocols="SSLv2,SSLv3,TLSv1" I can test the SSLv3 requests successfully now , but SSLv2 requests still fails. They were processing through success before the upgrade of Tomcat. I am using the JDK1.6 and Redhat platform and openssl version 0.9.8h. Please let me know if i can enable SSLv2 on the newer Tomcat. -Thanks Utkarsh
Re: Question related to Session management in Tomcat !
Thank You Mark On Wed, Nov 25, 2015 at 4:39 PM, Mark Thomas wrote: > On 25/11/2015 10:50, Utkarsh Dave wrote: > > Hello, > > > > I need inputs/answers on below points to implement a secure session > > management application > > Or if there is there any configuration that may need to be tuned to > improve > > below please point me to that > > A) > > Are Session IDs cryptographically strong and do not reveal sensitive > > information so that they can't be guessed easily or used to find attack > > vectors. > > Does we meet below > > 1. Does Strong entropy sources being used to generate the session ID > value > > Yes, it uses java.security.SecureRandom by default. > > > 2. Does Strong cryptographic algorithms being used to generate the > session > > ID value > > Yes, SHA1PRNG by default. > > > 3. Does the session ID value provides at least 128 bits of entropy. > > Yes, the session ID is 16 bytes / 128 bits long by default. > > > 4. Is the session ID value meaningless to prevent information disclosure > > attacks, allowing recovery of the contents of the ID and extract details > of > > the user, the session, or the inner workings of the web application. > > Yes. > > > B) > > Are the Session IDs fully validated before they may be used. > > When using session ID to keep authentication state and track user > progress > > within a web application, the application MUST treat the session ID as > > untrusted data, > > and sanitize and validate it before use. > > Yes. > > As with most things in Tomcat, configuration provides a lot of control > over session ID generation but the default settings meet the > requirements you set out above. > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Question related to Session management in Tomcat !
Hello, I need inputs/answers on below points to implement a secure session management application Or if there is there any configuration that may need to be tuned to improve below please point me to that A) Are Session IDs cryptographically strong and do not reveal sensitive information so that they can't be guessed easily or used to find attack vectors. Does we meet below 1. Does Strong entropy sources being used to generate the session ID value 2. Does Strong cryptographic algorithms being used to generate the session ID value 3. Does the session ID value provides at least 128 bits of entropy. 4. Is the session ID value meaningless to prevent information disclosure attacks, allowing recovery of the contents of the ID and extract details of the user, the session, or the inner workings of the web application. B) Are the Session IDs fully validated before they may be used. When using session ID to keep authentication state and track user progress within a web application, the application MUST treat the session ID as untrusted data, and sanitize and validate it before use. Thanks a lot for your time. Utkarsh Dave
Can we have number of RequestDispatcher (busy) logged in log files !
Hello, In tomcat 7 I wanted to know if there is a way we can log the number of request dispatcher threads used/busy/blocked, in log files. Or is there a mechanism that logs the number of request threads so that user can be warned about the request dispatcher threads if too many are being in busy state due to too many sessions or BLOCKED situations. Situation like this may result in DoS situation and tomcat becomes unresponsive. -Regards Utkarsh
Re: Tomcat manager application not using custom ErrorReportingValve !
Thanks a lot Mark. On Thu, Jul 30, 2015 at 11:50 AM, Mark Thomas wrote: > On 30/07/2015 07:18, Utkarsh Dave wrote: > > Hi All, > > > > My application has a custom reporting valve in server.xml > > > >> errorReportValveClass="com..valves.CustomErrorReportValve" > > name="localhost" unpackWARs="true"> > > > > But when I try to access https:///manager > > I get normal error window page of (the tomcat error page is at > > /tomcat/webapps/manager/WEB-INF/jsp/403.jsp > > " > > 403 Unauthorized > > > > You are not authorized to view this page. If you have not changed any > > configuration files, please examine the file conf/tomcat-users.xml in > your > > installation. That file must contain the credentials to let you use this > > webapp. > > .." > > > > How to have the manager application use the custom error valve ? > > Application configured error pages take precedence over any error > reporting valve. > > > Do i need to configure manager application separately? > > You could remove the error page settings from the Manager app's web.xml. > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Tomcat manager application not using custom ErrorReportingValve !
Hi All, My application has a custom reporting valve in server.xml But when I try to access https:///manager I get normal error window page of (the tomcat error page is at /tomcat/webapps/manager/WEB-INF/jsp/403.jsp " 403 Unauthorized You are not authorized to view this page. If you have not changed any configuration files, please examine the file conf/tomcat-users.xml in your installation. That file must contain the credentials to let you use this webapp. .." How to have the manager application use the custom error valve ? Do i need to configure manager application separately? -Thanks Utkarsh
Re: To log TLS sessions !
Thank you Christ. On Fri, Feb 13, 2015 at 10:03 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Utkarsh, > > On 2/13/15 12:39 AM, Utkarsh Dave wrote: > > Need your thoughts and comments on the requirement where we need > > to log/capture information when TLS sessions are setup, the logs > > will be logged to indicate successful or failed connection > > establishment or even connection being disconnected. > > > > RequestDumperFilter is one way but that will dump each and every > > requests and response in detail > > My first thought would be to see how the RequestDumperFilter does it, > and then only use that part of the code. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJU3idTAAoJEBzwKT+lPKRYvmcP/1rZ+DuMyTFq9rxyxYcVlH9I > s2gcCjSP4vXWEmwV6mTeVP6kD1v2ld8/ZsMcCI9kHPiT9XIFe8w4o9HJQ4vYsu1D > hwzNdIhSvYmQzijcUnDxy4M7bG43SRDrEoWLCgcbKx9SBCy5pnoh7fZ5Ubafmv3Z > 1eQ6LNha5bY+8CH7Vodkt9ISYZeBUnnWz6TpPlD/wLEst/tF4MyBCyEuqxxJXDMn > 9K8OPhnkoXGk2P4Q4dtl+f8CTKWXaWAVA4kynz75zhmaFy68B73bjI+VKubJUnrc > 65xsijSVE32ZtFoBxa9I/nw6NwjcvFfjNNvfq/OEZtDEwS7ji88p/J2VFJ3GzI7o > isYIuDHftiTeNjS0Q4eZ7EN9YtuuHn+a3tBzZhg6duBERu0aywjK0PEkbPWJP8BX > 9fIx75Rqy7iBFcD5rmnmDgRah+R9kqvnAWpYdJWL+CB2kq6mo+0HZT/NQMSZ0PHa > BTUIyJGac6DzToeyJ4HjFa8GPGAN68gJsVNX6NM+KUxVNSb6XaMTCTVxWic16QD0 > W5FDoEXU7MTEaVN8jUE58VJPIBrXMVbIO5dGuPrjNFqmGteClVN17ULRlGTx+2ru > k58MCN0uCRxlCfGQTky3BbcgwAACVpgWNx1dd7N9mfdbGnv92FDX/sU/V0DTeNqF > gHGXzkIPn8vfxyJFFAPr > =gnmt > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: To log TLS sessions !
Thanks Chris. Any other thoughts? On Fri, Feb 13, 2015 at 10:03 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Utkarsh, > > On 2/13/15 12:39 AM, Utkarsh Dave wrote: > > Need your thoughts and comments on the requirement where we need > > to log/capture information when TLS sessions are setup, the logs > > will be logged to indicate successful or failed connection > > establishment or even connection being disconnected. > > > > RequestDumperFilter is one way but that will dump each and every > > requests and response in detail > > My first thought would be to see how the RequestDumperFilter does it, > and then only use that part of the code. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJU3idTAAoJEBzwKT+lPKRYvmcP/1rZ+DuMyTFq9rxyxYcVlH9I > s2gcCjSP4vXWEmwV6mTeVP6kD1v2ld8/ZsMcCI9kHPiT9XIFe8w4o9HJQ4vYsu1D > hwzNdIhSvYmQzijcUnDxy4M7bG43SRDrEoWLCgcbKx9SBCy5pnoh7fZ5Ubafmv3Z > 1eQ6LNha5bY+8CH7Vodkt9ISYZeBUnnWz6TpPlD/wLEst/tF4MyBCyEuqxxJXDMn > 9K8OPhnkoXGk2P4Q4dtl+f8CTKWXaWAVA4kynz75zhmaFy68B73bjI+VKubJUnrc > 65xsijSVE32ZtFoBxa9I/nw6NwjcvFfjNNvfq/OEZtDEwS7ji88p/J2VFJ3GzI7o > isYIuDHftiTeNjS0Q4eZ7EN9YtuuHn+a3tBzZhg6duBERu0aywjK0PEkbPWJP8BX > 9fIx75Rqy7iBFcD5rmnmDgRah+R9kqvnAWpYdJWL+CB2kq6mo+0HZT/NQMSZ0PHa > BTUIyJGac6DzToeyJ4HjFa8GPGAN68gJsVNX6NM+KUxVNSb6XaMTCTVxWic16QD0 > W5FDoEXU7MTEaVN8jUE58VJPIBrXMVbIO5dGuPrjNFqmGteClVN17ULRlGTx+2ru > k58MCN0uCRxlCfGQTky3BbcgwAACVpgWNx1dd7N9mfdbGnv92FDX/sU/V0DTeNqF > gHGXzkIPn8vfxyJFFAPr > =gnmt > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
To log TLS sessions !
Hi all, Need your thoughts and comments on the requirement where we need to log/capture information when TLS sessions are setup, the logs will be logged to indicate successful or failed connection establishment or even connection being disconnected. RequestDumperFilter is one way but that will dump each and every requests and response in detail -Utkarsh
Re: SSL issue in tomcat
I don t think you will achieve what you want to via disabling SSL protocol using sslEnabledProtocols. The vulnerability "I think it is due to vulnerability in ssl 3.0 issue." will not stop access to the application. You may want to revert your changes back, and check the firewall settings or anything that can block the ports 8443, 8080 etc... Is there any exception in catalina.out? -Utkarsh On Tue, Jan 20, 2015 at 2:47 PM, Jason Y wrote: > Hi folks, > > Recently my application cannot be accessible in browser with https version. > I think it is due to vulnerability in ssl 3.0 issue. > > I checked my tomcat configuration and replaced sslProtocol="TLS" with > sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" to disable SSL 3.0. > > >connectionTimeout="2" > >redirectPort="8443" /> > > > protocol="org.apache.coyote.http11.Http11Protocol" > >maxThreads="150" SSLEnabled="true" scheme="https" > > secure="true" > >clientAuth="false" > > sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" keystoreFile="xxx" > > keystorePass="xxx" /> > > > > > Then I can open my application https link in browser. BUT, good time never > lasts too long, after several hours, I failed to access my https link > again. > > Anyone has any ideas about this? please share your suggestions...My tomcat > version is 7.0.55 > > Thank you all very much. > > On Tue, Jan 20, 2015 at 3:56 PM, Jason Y wrote: > > > Hi folks, > > > > Recently my application cannot be accessible in browser with https > > version. I think it is due to vulnerability in ssl 3.0 issue. > > > > I checked my tomcat configuration and replaced sslProtocol="TLS" with > > sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" to disable SSL 3.0. > > > > >>connectionTimeout="2" > >>redirectPort="8443" /> > >> >> protocol="org.apache.coyote.http11.Http11Protocol" > >>maxThreads="150" SSLEnabled="true" scheme="https" > >> secure="true" > >>clientAuth="false" > >> sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" keystoreFile="xxx" > >> keystorePass="xxx" /> > >> > > > > > > Then I can open my application https link in browser. BUT, good time > never > > lasts too long, after several hours, I failed to access my https link > > again. > > > > Anyone has any ideas about this? please share your suggestions...My > tomcat > > version is 7.0.55 > > > > Thank you all very much. > > >
Re: Can we Enable SSL protocol in Tomcat 7.0.57 ?
Thanks for the response. So would the desired changes in server.xml will be sslEnabledProtocols="SSL,TLS" -Thanks Utkarsh On Tue, Jan 6, 2015 at 1:47 PM, Mark Thomas wrote: > On 06/01/2015 07:46, Utkarsh Dave wrote: > > Hi Team, > > > > My project is planning to upgrade to Tomcat 7.0.57 that has the fix for > > POODLE vulnerability and have the SSL protocol disable by default. > > We were up till now using the manual configuration change in server.xml > in > > order to disable use of SSL. > > > > My questions is that after upgrading to Tomcat 7.0.57, is there any > similar > > configuraion change available, through which we can re enable SSL > protocols > > again. > > Yes. The only change in 7.0.57 is to the defaults. The configuration > attributes for SSL/TLS protocols that you used to exclude SSL can now be > used to restore SSL support if required. > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Can we Enable SSL protocol in Tomcat 7.0.57 ?
Hi Team, My project is planning to upgrade to Tomcat 7.0.57 that has the fix for POODLE vulnerability and have the SSL protocol disable by default. We were up till now using the manual configuration change in server.xml in order to disable use of SSL. My questions is that after upgrading to Tomcat 7.0.57, is there any similar configuraion change available, through which we can re enable SSL protocols again. Please let me know if my question is not clear. -Thanks Utkarsh Dave
Re: Unable to disable SSL in Tomcat 6 for poodle Vulnerability!
Ignoring the option to upgrade to Tomcat 7, i tried to configure server.xml in several differrent ways, but yet SSL protocol was enable. I see below update on Tomcat site ( http://ci.apache.org/projects/tomcat/tomcat6/docs/changelog.html ) about poodle fixes. Disable SSLv3 by default for the APR/native HTTPS connector. Disable SSLv3 by default (along with SSLv2 which was already disabled by default) in light of the recently announced POODLE vulnerability Are these being worked upon. Can you please tell me Changelog*Tomcat 6.0.43 (markt)* *Catalina* [image: fix] Assert that mapping result object is empty before performing mapping work in Mapper. (kkolinko) *Coyote* [image: fix] 53952 <http://issues.apache.org/bugzilla/show_bug.cgi?id=53952>: Add support for TLSv1.1 and TLSv1.2 for APR connector. Based upon a patch by Marcel Šebek. (schultz/jfclere) [image: fix] 57102 <http://issues.apache.org/bugzilla/show_bug.cgi?id=57102>: Fix bug that meant sslEnabledProtocols setting was not recognised for the HTTPS NIO connector. (markt) [image: add] Disable SSLv3 by default for the APR/native HTTPS connector. (markt/schultz) [image: fix] Do not increase remaining counter at end of stream in IdentityInputFilter. (kkolinko) [image: fix] Disable SSLv3 by default (along with SSLv2 which was already disabled by default) in light of the recently announced POODLE vulnerability (CVE-2014-3566). (markt) On Sun, Nov 2, 2014 at 11:56 PM, Hassan Schroeder < hassan.schroe...@gmail.com> wrote: > On Sun, Nov 2, 2014 at 10:09 AM, Utkarsh Dave > wrote: > > > Is there any other way to disable SSL in Tomcat 6. > > How many ways do you need? The process described in this thread > works as indicated with 6.0.37. > > -- > Hassan Schroeder hassan.schroe...@gmail.com > http://about.me/hassanschroeder > twitter: @hassan > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Unable to disable SSL in Tomcat 6 !
Hi Chris, Yes. openssl s_client succeeds (displays no exception) when I have sslProtocols="TLSv1" set? The latest releases of our project uses Tomcat 7, but to support older releaes we may not upgrade from Tomcat 6 to 7. Is there any other way to disable SSL in Tomcat 6. -Utkarsh On Sun, Nov 2, 2014 at 4:47 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Utkarsh, > > On 11/1/14 3:33 PM, Utkarsh Dave wrote: > > Thanks for the response. I am testing using below steps. > > > >> From another machine I am running this command: > > > > openssl s_client -ssl3 -msg -connect : > > > > > > HOST is the server ip (on the server where actually ssl needs to > > be disabled and server.xml is modified with sslProtocols="TLSv1" ) > > > > PORT is 8443 (tomcat) > > > > > > If the result of above command results in failure. It means SSL is > > disabled. > > Good. > > > How can i know if my JVM recognizes the particular protocol > > string. > > Well, if you use "TLSv1" and Tomcat doesn't emit an error message, > then you should be good. > > So... does openssl s_client succeed when you have sslProtocols="TLSv1" > set? > > You should really upgrade to a more recent version of Tomcat 6.0.x, or > maybe even Tomcat 7.x or 8.x. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJUVWoLAAoJEBzwKT+lPKRY8JIQAIVYkWZJ5UWOxE5uwoZYtzGJ > LUGDUyWP4+JCmWLyXfeiNF/jR/oz2ApTdH0mWF2/Qs1mhDd4VDmgwVg4t8s1MGAd > qXeuV3VP4E4d3CkHhfwy42LFKLt2YjUfiYfip5HNFWta71n6wBs5ey7qJ4cf3gQn > wjg/FY3HjVlR2+flB24TZbetPJyEbhXDi9NKJv7JCXwX8TPAc6ZFEFxl8qIyE9wF > QGu5HbZDsZWU8YuCzypbttyeklX6i3TxUlITIB4SK6DhIklXXGjaOuIRFtZrnvx/ > ATFxgj9xkdkU/9Q/eRKcU9D/lfsxs3P0+IcyXUV6iaquhQ4MZsdSS3zgbD6LuKJC > pbf0SLcQj9+HI51vBWdwkgnlN+84vZcUk/BBBd2X+BJ+OaxuOO9HVBlyAuUUUaCc > UlEbFLf/O5dNa3B6fVSy39NAm0/MzJtCdzNRPcrVp+1hZqiJwqxgVWAOgbwK3Osa > UrbBCzNoFUb0NoGFyFxmgyXCWYHVWwMF/6pBG9IaxKwopU53QbDvCoUJZje7ePpw > jL5r6s8TefRvMo6Qr6/0re7iqFedTy9YYITBXlyUdLlOIsPAu2uYn6AmDKFzSmah > dEAAdNra2WIs0syANZvRSFW/GBuABdeAevaAvIXuNUP8UHjpEEttErv+CVKGJf2Y > P5Tcoa5uWIPY+hAtzfbl > =ctAo > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Unable to disable SSL in Tomcat 6 !
Hi Chris, Thanks for the response. I am testing using below steps. >From another machine I am running this command: openssl s_client -ssl3 -msg -connect : HOST is the server ip (on the server where actually ssl needs to be disabled and server.xml is modified with sslProtocols="TLSv1" ) PORT is 8443 (tomcat) If the result of above command results in failure. It means SSL is disabled. How can i know if my JVM recognizes the particular protocol string. -Thanks Utkarsh On Sat, Nov 1, 2014 at 12:52 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Utkarsh, > > On 10/31/14 11:52 AM, Utkarsh Dave wrote: > > Nothing helped much. Please let me know how can i disable SSL in > > Tomcat 6.0.37. > > > > I tried below configuration in server.xml on Tomcat 6.0.37 > > > > > protocol="org.apache.coyote.http11.Http11Protocol" maxThreads="150" > > SSLEnabled="true" scheme="https" secure="true" clientAuth="false" > > sslProtocols = "TLSv1" > > > > The same with sslEnabledProtocols instead of sslProtocols worked > > for Tomcat 7. I am also following solution at > > https://access.redhat.com/solutions/1232233 > > The configuration attributes "protocols", "sslProtocols", and > "sslEnabledProtocols" are all equivalent in Tomcat 6.0.38 and later. > Before Tomcat 6.0.38, "protocols" and "sslProtocols" are equivalent. > > So it shouldn't really matter which one you use. But since you are > using 6.0.37, then you definitely can't use "sslEnabledProtocols". > > So.. what's the problem? With the above configuration, what protocols > end up being enabled? How are you performing your testing? > > You are using the Java BIO connector so it's using JSSE for crypto. > Those settings you have should work. The default for "sslProtocol" is > "TLS" which should get you pretty much everything, and restricting > sslProtocols to "TLSv1" should get you only TLSv1, as long as your JVM > recognizes that particular protocol string. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJUU+FoAAoJEBzwKT+lPKRYHscQAIRhapwkrWIhVvGv6GJxkUVV > uhWrZQm/mBj4+kGCy+/Ca3b9oE6i5IKAQCLRxF5sVDABplZcAM80w8HSAXcSUtXd > vw1lLxZ7/0iwJ5sukceypw+zlbSgsg3OFCDBBpBrk9bikUBVQUN5PCmMxnsyS8X3 > fOMi8hrEbqHSZWu6qPq3I5u4BJVBSvzCpGlF5KXrQH1kovCekULH5HAmQ93V3umL > 6oD06LzF4Qef5x6wUHCRb8Kz7o7xC9Sk+bclvajJx2UCWAH5flEvlT+gR0+ERFbT > B4M6fSvEpdrOHz6jsgixOBkJz1yXsH2d6uNztvtitIwuDCHP6T32xQ3lWvwma4Cn > 3prT1Z+ytJUI3E9MhEwWZ1rWNSZgR/alm3k+zmud9Gm3Msr+Zl61uKKsAQPW8/YG > BlfC4c1PR3VpquhqDP6eSw9E4CP/4LwvO0mQO7+t4ZDSEmxwT9DSBjvy5tjWRqo7 > flmtwFsfVkQ/qwCjgJFRneRYM4+7zJ8IVnEhnXLiXQhZYU8NMAJ1bcxHpd9Yz6O7 > gQXQRlA7bZDW2dgRNsMwimVPovY+36XrS92Bsn8VEcc/uuLx/XyGgcqYnNnhvfjk > UKpB4Uj38zjjBBEnjYnI5JVmDBam5I44Y12eSsxBS0elvBGc3U3Pv8W7ijFz74u7 > NzqKsmZJjk2x5bbHZERQ > =9f5b > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Unable to disable SSL in Tomcat 6 !
Nothing helped much. Please let me know how can i disable SSL in Tomcat 6.0.37. I tried below configuration in server.xml on Tomcat 6.0.37 https://access.redhat.com/solutions/1232233 -Regards Utkarsh On Thu, Oct 30, 2014 at 10:30 PM, Mark Thomas wrote: > On 30/10/2014 16:38, Utkarsh Dave wrote: > > Hello all, > > > > To avoid poodle vulnerability we are trying to disable SSL v3 and all its > > versions through below configuration. > > > > >maxThreads="150" SSLEnabled="true" scheme="https" > secure="true" > >clientAuth="false" sslProtocols = "TLSv1" /> > > > > > > Can you please tell me if we are missing anything and how can we make > this > > thing work? > > http://wiki.apache.org/tomcat/Security/POODLE > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Unable to disable SSL in Tomcat 6 !
Hello all, To avoid poodle vulnerability we are trying to disable SSL v3 and all its versions through below configuration. Can you please tell me if we are missing anything and how can we make this thing work? Thanks in advance -Utkarsh
Release plans of Tomcat 6.0.42/6.0.43
Hi, Can i please know when Tomcat 6.0.43 will be released or any plans of it? If not the date month in which it will be released? -Thanks Utkarsh Dave
How can we configure deployXML=true in security manager ?
We upgraded from Tomcat 7.0.41 to tomcat 7.0.53. We are starting the Tomcat as "-security" so as to enable security manager. I also see the changelog of 7.0.48 mentioning about this change "When running under a security manager, change the default value of the Host's deployXML attribute to false. add If a Host is configured with a value of false for deployXML, a web application has an embedded descriptor at META-INF/context.xml and no explicit descriptor has been defined for this application, do not allow the application to start. The reason for this is that the embedded descriptor may contain configuration necessary for secure operation such as a RemoteAddrValve. " As a result many of the applications are not starting in my project. How can we fix this? -Thanks Utkarsh
Handshake Failure error !
Hi, We are running Tomcat 6.0.37 and Java JDK 1.6.0_60 We recently upgraded to JDK 1.6.0_75 and recieved below error at several places javax.net.ssl.SSLException: Fatal Alert received: Handshake Failure We debugged and after analysis found that if we remove below 3 ciphers suits from server.xml file TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA The error is no more seen. I need your opinion in order to proceed with the changes. 1.What will be the effect of removing these cipher? 2. Found this link on ciphers http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html The cipher codes I mentioned above have been marked as 'X'. Most of the cipher codes mentioned in my server.xml are marked as 'X'. So I am confused as to am I on correct path of removing these problematic cipher from server.xml or not. Can you help in answering the 2 questions above? Thanks for your help in advance. -Utkarsh
Release date of Tomcat 6.0.42 ?
Can i please know when Tomcat 6.0.42 will be released. If not exact an estimation will also help. -Thanks Utkarsh - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
"NoClassDefFoundError: org/apache/tomcat/util/descriptor/LocalResolver" Error while building project after Tomcat upgrade to 7.0.53 from 7.0.41 !
I am trying to upgrade my Tomcat from 7.0.41 to the latest release 7.0.53 available and the project build failed with below error. java.lang.NoClassDefFoundError: org/apache/tomcat/util/descriptor/LocalResolver at org.apache.jasper.xmlparser.ParserUtils.(ParserUtils.java:69) at org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:94) at org.apache.jasper.compiler.JspConfig.init(JspConfig.java:243) And same error from multiple places also. Is this a known issue? Regards -Utkarsh
"NoClassDefFoundError: org/apache/tomcat/util/descriptor/LocalResolver" Error while building project after Tomcat upgrade to 7.0.53 from 7.0.41 !
I am trying to upgrade my Tomcat from 7.0.41 to the latest release 7.0.53 available and the project build failed with below error. java.lang.NoClassDefFoundError: org/apache/tomcat/util/descriptor/LocalResolver at org.apache.jasper.xmlparser.ParserUtils.(ParserUtils.java:69) at org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:94) at org.apache.jasper.compiler.JspConfig.init(JspConfig.java:243) And same error from multiple places also. Is this a known issue? Regards -Utkarsh
Re: Catalina start problem
I once received similar exception while starting tomcat, but i was trying to modify the web.xml with incorrect tags. Try to get the thread dumps and track the changes that were performed before your attempt to start tomcat. On Wed, Apr 2, 2014 at 1:53 PM, Neeraj Sinha wrote: > I am trying to start tomcat on linux and I am getting LifecycleException > exception whose snippet is below: > > Apr 2, 2014 8:33:53 AM org.apache.catalina.core.AprLifecycleListener init > INFO: The APR based Apache Tomcat Native library which allows optimal > performance in production environments was not found on the > java.library.path: > > /usr/java/jdk1.6.0_38/jre/lib/amd64/server:/usr/java/jdk1.6.0_38/jre/lib/amd64:/usr/java/jdk1.6.0_38/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib > Apr 2, 2014 8:33:53 AM org.apache.coyote.AbstractProtocol init > INFO: Initializing ProtocolHandler ["http-bio-8080"] > Apr 2, 2014 8:33:53 AM org.apache.coyote.AbstractProtocol init > INFO: Initializing ProtocolHandler ["ajp-bio-8009"] > Apr 2, 2014 8:33:53 AM org.apache.catalina.startup.Catalina load > INFO: Initialization processed in 890 ms > Apr 2, 2014 8:33:53 AM org.apache.catalina.startup.Catalina start > SEVERE: Catalina.start: > org.apache.catalina.LifecycleException: Failed to start component > [StandardServer[8005]] > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154) > at org.apache.catalina.startup.Catalina.start(Catalina.java:684) > 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:322) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:451) > Caused by: java.lang.NoSuchMethodError: > org.apache.naming.NamingContext.setExceptionOnFailedWrite(Z)V > at > > org.apache.catalina.core.NamingContextListener.lifecycleEvent(NamingContextListener.java:264) > at > > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) > at > > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) > at > > org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:724) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > ... 7 more > Apr 2, 2014 8:33:53 AM org.apache.catalina.startup.Catalina start > INFO: Server startup in 6 ms > > One reason I could guess for this is that Tomcat jar may not be proper but > I have checked that and that looks fine to me. > > Appreciated if somebody could help me. >
Can we increase the logging in localhost_access.log
Hi, We are using Tomcat 7.0.41. One of my customer faces 404 error while accessing the web application. This continues for some time and goes away automatically without giving us time to debug. We dont have any other clue. Everything else works fine. all services are running great. No issue with Tomcat server also. It seems customer also verified the network settings and firewall. We see 404 error in localhost_access so this the place from where we can dig into. Is there any way we can enhance the logging/information in localhost_access_log. Or then how can debug what happens between user requests and 404 response,? -Utkarsh
Re: Issue while configuring CSRFPreventionFilter !
Thanks Konstantin. My version of TOMCAT is 7.0.41 you said with this configuration i will not be able to access ROOT/index.html or any of the images, css or js files. What can i do to overcome this if i still want to go ahead configuring the $TOMCAT_HOME/conf/web.xml. Can i add them in entryPoints. ? I want to do it in this file because i dont want my 50 + webapps to modify there respective web.xml file. Rather we can configure them at 1 common place. -Thanks Utkarsh On Fri, Mar 21, 2014 at 12:17 PM, Konstantin Kolinko wrote: > 2014-03-21 10:09 GMT+04:00 Utkarsh Dave : > > Hi all, > > > > I am trying to configure the Tomcat inbuilt filter > > (tomcat.valves.CiscoResponseHeaderFilter) into my > $TOMCAT_HOME/conf/web.xml > > 1. The above file provides defaults for all web applications. It is > unwise to modify it. > > E.g. with such configuration you wouldn't be able to access > ROOT/index.html or any of the images, css or js files. > > > ... > > > > But after doing this Tomcat server stuck in starting status and do not > > starts completely. > > 2. Read the logs. > > 3. If it is "stuck", take several thread dumps to see what exactly it is > doing. > If you do not know how to take thread dumps, see "Howto" page in Tomcat > FAQ. > > > If I comment out the filter, Tomcat starts properly. > > ... > > 4. As mentioned on the page below, what is your version of Tomcat? > http://tomcat.apache.org/lists.html#tomcat-users > > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Issue while configuring CSRFPreventionFilter !
Hi all, I am trying to configure the Tomcat inbuilt filter (tomcat.valves.CiscoResponseHeaderFilter) into my $TOMCAT_HOME/conf/web.xml CSRF org.apache.catalina.filters.CsrfPreventionFilter entryPoints /index.jsp CSRF /* But after doing this Tomcat server stuck in starting status and do not starts completely. If I comment out the filter, Tomcat starts properly. I verified the web.xml of Tomcat manager ( $TOMCAT_HOME/webapps/manager/WEB-INF/web.xml) where this filter is configured by default and found that in below is used in filter mapping CSRF HTMLManager jsp So when use the same in $TOMCAT_HOME/conf/web.xml, Tomcat works properly. Why i am not able to map the filter to /* url? What is the difference between using servlet name and url pattern ? Can anyone provide the inputs and help in this regard. Thanks for your time in advance. -Utkarsh
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
Did you try generating / regenerating your certificated. Once done put it under your security directory within your jdk home On Tue, Mar 4, 2014 at 11:10 PM, Bill Davidson wrote: > We tried to upgrade a production server to Tomcat 7 yesterday and it > broke our printing applet that we use to control a printer in its native > printer language. > > This seemed odd to us because it worked perfectly in testing. When we > go direct to our production servers (bypassing the Cisco load balancer > which is doing SSL for us), it also works fine in production. > > The only thing that's changed is using Tomcat 7. > > We only have one connector in server.xml > > protocol="AJP/1.3" > address="127.0.0.1" > redirectPort="443" > connectionTimeout="60" > maxThreads="1000" > maxPostSize="5242880" > maxParameterCount="66000" /> > > The Java console is giving an SSLHandshakeException > > v: dump thread stack > x: clear classloader cache > 0-5: set trace level to > > cache: Initialize resource manager: com.sun.deploy.cache. > ResourceProviderImpl@c77c8 > basic: Added progress listener: sun.plugin.util. > ProgressMonitorAdapter@a2bfd5 > basic: Plugin2ClassLoader.addURL parent called for > https://myhost.mydomain/myapp/applets/print.jar > security: Accessing keys and certificate in Mozilla user profile: null > security: JSS is not configured > network: Cache entry not found [url: https://myhost.mydomain/myapp/ > applets/print.jar, version: null] > network: Connecting https://myhost.mydomain/myapp/applets/print.jar with > proxy=DIRECT > network: Cache entry not found [url: file:/C:/Program%20Files%20( > x86)/Java/jre7/lib/ext/sunec.jar, version: null] > network: Cache entry not found [url: file:/C:/Program%20Files%20( > x86)/Java/jre7/lib/ext/sunjce_provider.jar, version: null] > network: Connecting http://myhost.mydomain:443/ with proxy=DIRECT > javax.net.ssl.SSLHandshakeException: Remote host closed connection during > handshake > at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source) > at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown > Source) > at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) > at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) > at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source) > at > sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown > Source) > at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(Unknown > Source) > at sun.plugin.PluginURLJarFileCallBack.connect(Unknown Source) > at sun.plugin.PluginURLJarFileCallBack.retrieve(Unknown Source) > at sun.net.www.protocol.jar.URLJarFile.retrieve(Unknown Source) > at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source) > at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source) > at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source) > at sun.plugin.net.protocol.jar.CachedJarURLConnection.connect(Unknown > Source) > at > sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFileInternal(Unknown > Source) > at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown > Source) > at com.sun.deploy.security.DeployURLClassPath$JarLoader.getJarFile(Unknown > Source) > at > com.sun.deploy.security.DeployURLClassPath$JarLoader.access$1000(Unknown > Source) > at com.sun.deploy.security.DeployURLClassPath$JarLoader$1.run(Unknown > Source) > at java.security.AccessController.doPrivileged(Native Method) > at com.sun.deploy.security.DeployURLClassPath$JarLoader.ensureOpen(Unknown > Source) > at com.sun.deploy.security.DeployURLClassPath$JarLoader.(Unknown > Source) > at com.sun.deploy.security.DeployURLClassPath$3.run(Unknown Source) > at java.security.AccessController.doPrivileged(Native Method) > at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown > Source) > at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown > Source) > at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown > Source) > at sun.plugin2.applet.Plugin2ClassLoader$1.run(Unknown Source) > at java.security.AccessController.doPrivileged(Native Method) > at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown > Source) > at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source) > at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source) > at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source) > at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source) > at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source) > at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source) > at java.lang.ClassLoader.loadClass(Unknown Source) > at sun.plugin2.applet.Plugin2Cla
Re: Error while upgrading to Tomcat 7.0.52
Hi Prashant - I assume there will not be any consequence of replacing validateXML with validateTld? -Thanks for the quick response. -Utkarsh On Mon, Mar 3, 2014 at 4:19 PM, Prashant Kadam wrote: > On Mon, Mar 3, 2014 at 3:58 PM, Utkarsh Dave > wrote: > > > To be more specific, i upgraded Tomcat in my application from Tomcat > 7.0.41 > > to 7.0.52. > > > > Quick response is appreciable as the build process is on hold critical > > services are shut down. > > > > -Thanks > > > > > > On Mon, Mar 3, 2014 at 3:39 PM, Utkarsh Dave > > wrote: > > > > > Hi, > > > > > > I upgraded my application to 7.0.52 from 7.0.41. After upgrading while > > > building and compiling whole application I am recieving error > > > jasper2 doesn't support the "validateXml" attribute > > > While looking in 1 of the blogs i found that the solution for this will > > be > > > available only on 7.0.53 which is not yet available. > > > Can you please let me know how i can proceed with this. > > > If in case you need further details please let me know or feel free to > > > reach to me in India IST. > > > Hi Utkarsh > > Please use validateTld instead of validateXML. It would work . > > > > > > > > -Utkarsh Dave > > > +919739903066 > > > Technial Lead > > > Infosys Limited at Cisco. > > > e-city, Bangalore. India > > > > > > > > > -- > ~ Prashant Kadam >
Re: Error while upgrading to Tomcat 7.0.52
Thanks Konstantin for the quick response. We are using false value, so i assume i can remove the attribute. As there are many level of developers involved, deleting and again adding it, will be difficult to track. I recieved another response, if i can replace validateTld instead of validateXML. Do you see any issue if we adopt this approach. -Thanks Utkarsh On Mon, Mar 3, 2014 at 4:16 PM, Konstantin Kolinko wrote: > 2014-03-03 14:28 GMT+04:00 Utkarsh Dave : > > To be more specific, i upgraded Tomcat in my application from Tomcat > 7.0.41 > > to 7.0.52. > > > > Quick response is appreciable as the build process is on hold critical > > services are shut down. > > > > If you use the value of "false", remove the attribute. > > "false" is the default value here. There is no reason to use it explicitly. > > If you use the value of "true", remove the attribute now and restore > it back when 7.0.53 is released. > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Error while upgrading to Tomcat 7.0.52
To be more specific, i upgraded Tomcat in my application from Tomcat 7.0.41 to 7.0.52. Quick response is appreciable as the build process is on hold critical services are shut down. -Thanks On Mon, Mar 3, 2014 at 3:39 PM, Utkarsh Dave wrote: > Hi, > > I upgraded my application to 7.0.52 from 7.0.41. After upgrading while > building and compiling whole application I am recieving error > jasper2 doesn't support the "validateXml" attribute > While looking in 1 of the blogs i found that the solution for this will be > available only on 7.0.53 which is not yet available. > Can you please let me know how i can proceed with this. > If in case you need further details please let me know or feel free to > reach to me in India IST. > > -Utkarsh Dave > +919739903066 > Technial Lead > Infosys Limited at Cisco. > e-city, Bangalore. India >
Error while upgrading to Tomcat 7.0.52
Hi, > > I upgraded my application to 7.0.52 from 7.0.41. After upgrading while > building and compiling whole application I am recieving error > jasper2 doesn't support the "validateXml" attribute > While looking in 1 of the blogs i found that the solution for this will be > available only on 7.0.53 which is not yet available. > Can you please let me know how i can proceed with this. > If in case you need further details please let me know or feel free to > reach to me in India IST. > > -Utkarsh Dave > +919739903066 > Technial Lead > Infosys Limited at Cisco. > e-city, Bangalore. India >
