Re: Tomcat and MySQL in Azure Cloud
On 17 Jul 2010, at 03:12, Praveen Sripati praveensrip...@gmail.com wrote: Thanks for the reply. 1. The primary advantage of the cloud is scalability. We can increase servers from 1 to 100 within minutes based on the load. So, initially the JDBC URL might have 1 IP and it should be updated to have 100 IPs. So, the JDBC URL has to updated dynamically with the number of MySQL instances. Not sure if Azure provides a resolvable name, even if it does the JDBC URL has to be updated dynamically to reflect all the names of the new MySQL instances. You are missing the point. Stop fixating on the db URL, you will not be able to dynamically update it, you will not be able to dynamically recreate a DBCP datasource. Even if you could this would be a really BAD strategy as it would mean each Tomcat would have to pause and wait for all requests to stop processing before each db pool is refreshed. The pool refresh operation could take a whole minute, if your clients are on a slow network connection. The Tomcat instance would be unavailable for the whole period. You would need to write your own DataSource factory to do such a thing, which I wouldn't recommend. Have you load tested your app, how do you know that your proposed strategy will solve your problem? Do you not need more Tomcat instances too? p On Fri, Jul 16, 2010 at 10:19 PM, Pid p...@pidster.com wrote: On 16 Jul 2010, at 15:56, Praveen Sripati praveensrip...@gmail.com wrote: We are in the process of migrating Tomcat and MySQL to Microsoft Azure Cloud and facing challenges due to the dynamic nature of the cloud like allocation of dynamic ip and ports to the instances of Tomcat MySQL in Azure. Because of this behavior Tomcat needs to 1) Dynamically update the ip and ports of the different MySQL instances in the JDBC URL ( http://dev.mysql.com/doc/refman/5.5/en/connector-j-reference-replication-connection.html ). Suppose the following is the JDBC URL, then it has to be updated in Tomcat at run-time when a new instance of MySQL is bought up or an instance of MySQL is bought down. So don't put the IP address in there, put a resolvable name instead and dynamically update that - which is a more conventional way of doing things. url=jdbc:mysql:replication://127.0.0.1:5104,127.0.0.1:5108, 127.0.0.1:5112, 127.0.0.1:5116,127.0.0.1:5116/itops 2) We are using DBCP (http://commons.apache.org/dbcp/) for connection pooling. Similarly when a new instance of MySQL is bought up or an instance of MySQL is bought down the pool has to be updated dynamically accordingly at run-time. While apps are using the pool? Good luck with that. You'd be better off pooling the DB and having something work out where to route the db pool connections and just point DBCP at that. p Has anyone come across a solution for these problems while deploying Tomcat and MySQL in Cloud? Thanks, Praveen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Praveen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Is it possible to disable caching/force reloading of JNDI resources?
Hi guys, I'm stuck with a JNDI resource object factory problem. Hopefully you can help me out with this issue. My idea was to provide multiple web applications running inside a Tomcat instance with configuration properties from config files located outside the WAR file of the applications. I'm currently trying to provide these configuration properties with a global naming resource (defined inside the server.xml) which is consumed by the said applications to keep the configuration container independent and to avoid direct file access from a web application. So far almost everything already works perfectly! Except that Tomcat obviously caches resources which are looked up via JNDI. This way I have to restart Tomcat every time the external config files changes because the web applications never access my ObjectFactory again after Tomcat has cached the result of the ObjectFactory. Accordingly to the documentation an implementation of ObjectFactory should be accessed each time a web application looks it up with its JNDI key. But that's definitely not the case here. Any ideas or thoughts on this issue? Is there any way to disable this behavior of Tomcat's JNDI resource management? Or any comments on this plan to externalize the application configuration in general? Thanks in advance! Marco - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 7: IllegalArgumentException: taglib definition not consistent with specification version
On 16/07/2010 18:23, Edoardo Panfili wrote: Hy, I did I try with tomcat 7 uploading my application (that works fine with 6.0.26). the application does not starts up and I can see The tag lib element is not correct. It should be: taglib xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; version=2.1 Note the difference in the xsi:schemaLocation Mark -- 16-lug-2010 19.15.15 org.apache.catalina.startup.ContextConfig parseWebXml GRAVE: Parse error in application web.xml file at jndi:/localhost/application/WEB-INF/web.xml java.lang.IllegalArgumentException: taglib definition not consistent with specification version -- the start of taglib.tld is ?xml version=1.0 encoding=UTF-8? taglib xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; version=2.1 and the start of web.xml is ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd; version=2.5 I did some try but none usefull (nothing also on goole). Can I use taglib 2.1 with servlet 2.5? Where can I find this kind of informations? thank you Edoardo - 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: how to embed tomcat 7
On 16/07/2010 22:09, Caldarale, Charles R wrote: From: Ikonne, Ike [mailto:ike_iko...@stercomm.com] Subject: how to embed tomcat 7 can someone point to me on how I could go about embedding Tomcat into my application. I don't think anyone has properly documented how to do this, but the first set of APIs you need are here: http://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/startup/Tomcat.html And take a look at the unit tests in Tomcat 7 for numerous examples. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is it possible to disable caching/force reloading of JNDI resources?
On 17/07/2010 09:50, Marco Ehrentreich wrote: Accordingly to the documentation an implementation of ObjectFactory should be accessed each time a web application looks it up with its JNDI key. But that's definitely not the case here. What documentation? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat7 HTTPS APR Performance
On 07/16/2010 09:08 AM, shivanic wrote: Hello, For comparing performance of Apache Tomcat 7 with APR and Jboss Web Server with APR version 2.1.4 with Tomcat 7 we have done a load test of an app. Your results only show that you have used load testing wrongly. Hitting the server with the simple DoS tool won't give you any relevant relevant info unless you are hitting the web application that has constant response timeout (a bit oxymoron). Such web applications are for example Default servlet, which won't also give you the correct results, cause depending on the file size APR might choose to serve that via OS sendfile, in which case OS might cache that resource and give you the faulty sense of speed. Also the JVM might have it's own logic for GC (easily observable by multiple runs) However if your web application access the external resource (database or something) that has variable response time, all you get as result of testing is the state of that resource availability at the time test was run, not the performance characteristics of the application server. Just to prove my point, use your current test for any of the application servers you've tested so far, and repeat the same test with some random time between test runs, then do the same thing each time restarting the app server, and cleaning up the log files, and you'll see that numbers simply make no sense :) Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is it possible to disable caching/force reloading of JNDI resources?
Am 17.07.2010 12:56, schrieb Mark Thomas: On 17/07/2010 09:50, Marco Ehrentreich wrote: Accordingly to the documentation an implementation of ObjectFactory should be accessed each time a web application looks it up with its JNDI key. But that's definitely not the case here. What documentation? Mark Sorry, I'll try to find the said documentation again. I think it was something from the original Tomcat documentation but I can't find it at the moment. Maybe I missunderstood it but at least it didn't mention that the result of an ObjectFactory is only produced once and then cached by Tomcat. Can you tell me some more details about this issue? Or would you recommend a completely different approach? Marco - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 7: IllegalArgumentException: taglib definition not consistent with specification version
On 17/07/10 12.50, Mark Thomas wrote: On 16/07/2010 18:23, Edoardo Panfili wrote: Hy, I did I try with tomcat 7 uploading my application (that works fine with 6.0.26). the application does not starts up and I can see The tag lib element is not correct. It should be: taglib xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; version=2.1 Note the difference in the xsi:schemaLocation I changed the element but it raises the same error. After that I removed the whole taglib element, now the file is incorrect I know, but the exception is still there, with another one he markup in the document following the root element must be well-formed. the second is comprensible for me. Is it possible that the error is in another file? Edoardo -- 16-lug-2010 19.15.15 org.apache.catalina.startup.ContextConfig parseWebXml GRAVE: Parse error in application web.xml file at jndi:/localhost/application/WEB-INF/web.xml java.lang.IllegalArgumentException: taglib definition not consistent with specification version -- the start of taglib.tld is ?xml version=1.0 encoding=UTF-8? taglib xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; version=2.1 and the start of web.xml is ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd; version=2.5 I did some try but none usefull (nothing also on goole). Can I use taglib 2.1 with servlet 2.5? Where can I find this kind of informations? thank you Edoardo - 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: tomcat 7: IllegalArgumentException: taglib definition not consistent with specification version
On 17/07/2010 14:16, Edoardo Panfili wrote: On 17/07/10 12.50, Mark Thomas wrote: The tag lib element is not correct. It should be: taglib xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; version=2.1 Note the difference in the xsi:schemaLocation I changed the element but it raises the same error. OK. At least that is one possible issue fixed. How are you defining you taglibs in web.xml? Are you using: tablib ... /taglib or jsp-config tablib ... /taglib /jsp-config? ? After that I removed the whole taglib element, now the file is incorrect I know, but the exception is still there, with another one he markup in the document following the root element must be well-formed. the second is comprensible for me. Is it possible that the error is in another file? No. Looks like you removed the tablib ... element but left the /taglib. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 7: IllegalArgumentException: taglib definition not consistent with specification version
On 17/07/10 15.57, Mark Thomas wrote: On 17/07/2010 14:16, Edoardo Panfili wrote: On 17/07/10 12.50, Mark Thomas wrote: The tag lib element is not correct. It should be: taglib xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; version=2.1 Note the difference in the xsi:schemaLocation I changed the element but it raises the same error. OK. At least that is one possible issue fixed. How are you defining you taglibs in web.xml? Are you using: tablib ... /taglib this one jsp-config tablib ... /taglib /jsp-config? but this one works! also with the wrong schemaLocation. Without your help I can't figure the meaning of the exception. Is Tomcat supposing a specification version using the presence/absence of this tag? thank you. After that I removed the wholetaglib element, now the file is incorrect I know, but the exception is still there, with another one he markup in the document following the root element must be well-formed. the second is comprensible for me. Is it possible that the error is in another file? No. Looks like you removed thetablib ... element but left the/taglib. yes. I was only I try (removing the element the error remains, it was possible that the error was not there). Thank you again Edoardo - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 7: IllegalArgumentException: taglib definition not consistent with specification version
On 17/07/2010 15:21, Edoardo Panfili wrote: On 17/07/10 15.57, Mark Thomas wrote: On 17/07/2010 14:16, Edoardo Panfili wrote: On 17/07/10 12.50, Mark Thomas wrote: The tag lib element is not correct. It should be: taglib xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; version=2.1 Note the difference in the xsi:schemaLocation I changed the element but it raises the same error. OK. At least that is one possible issue fixed. How are you defining you taglibs in web.xml? Are you using: tablib ... /taglib this one jsp-config tablib ... /taglib /jsp-config? but this one works! also with the wrong schemaLocation. Without your help I can't figure the meaning of the exception. Is Tomcat supposing a specification version using the presence/absence of this tag? thank you. No. Tomcat 7 is requiring that if you declare your web application to be using version 2.5 of the Servlet specification that you declare your tag libraries as required by schema for that version of the spec. You were trying to use an old way old defining tag libraries from an older (2.3?) version of the spec. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat access logs
Hi, How do we configure access logs for tomcat so that we get details similar to apache-httpd server? e.g. I would like to view (HTTP) request type , IP address etc. in my logs. Any suggestions or resources on how to configure it? Thanks, jM.
Re: tomcat access logs
On 17/07/2010 22:24, Johan Martinez wrote: Hi, How do we configure access logs for tomcat so that we get details similar to apache-httpd server? e.g. I would like to view (HTTP) request type , IP address etc. in my logs. Any suggestions or resources on how to configure it? http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Access_Log_Valve Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat access logs
Thanks a lot... -- jM. On Sat, Jul 17, 2010 at 4:26 PM, Mark Thomas ma...@apache.org wrote: On 17/07/2010 22:24, Johan Martinez wrote: Hi, How do we configure access logs for tomcat so that we get details similar to apache-httpd server? e.g. I would like to view (HTTP) request type , IP address etc. in my logs. Any suggestions or resources on how to configure it? http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Access_Log_Valve Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
IP based request filters for admin/manager
I was wondering how to configure Request Filters to allow access to admin, manager, status-report, etc... I followed tomcat doc: http://tomcat.apache.org/tomcat-5.5-doc/config/context.html#Request_Filters and I was able to restrict access by specifying webapp names, e.g.: [[[ Context path=/manager Valve className=org.apache.catalina.valves.RemoteAddrValve allow=127.0.0.1 deny=/ /Context ]]] How can I deny access to default welcome/index page, changelog, release-notes etc.? I know just restricting access to default welcome/index page does not restrict access to manager or admin links on that page. Still, I would like to restrict access to welcome/index page in addition to admin/manager webapps. I have tried / and /ROOT and it didn't work. Any help or suggestions? Thanks, jM.
Re: IP based request filters for admin/manager
The first line should have been: I was wondering how to configure Request Filters to s/allow/RESTRICT/ access to admin, manager, status-report, etc.. :) jM. On Sat, Jul 17, 2010 at 11:19 PM, Johan Martinez jmart...@gmail.com wrote: I was wondering how to configure Request Filters to allow access to admin, manager, status-report, etc... I followed tomcat doc: http://tomcat.apache.org/tomcat-5.5-doc/config/context.html#Request_Filters and I was able to restrict access by specifying webapp names, e.g.: [[[ Context path=/manager Valve className=org.apache.catalina.valves.RemoteAddrValve allow=127.0.0.1 deny=/ /Context ]]] How can I deny access to default welcome/index page, changelog, release-notes etc.? I know just restricting access to default welcome/index page does not restrict access to manager or admin links on that page. Still, I would like to restrict access to welcome/index page in addition to admin/manager webapps. I have tried / and /ROOT and it didn't work. Any help or suggestions? Thanks, jM.
RE: IP based request filters for admin/manager
From: Johan Martinez [mailto:jmart...@gmail.com] Subject: IP based request filters for admin/manager How can I deny access to default welcome/index page, changelog, release-notes etc.? If you're deploying Tomcat in any kind of environment that requires securing access to various components, you would normally replace the default webapp (ROOT) with one of your own, thereby eliminating the changelog, release-notes, etc. If you want to restrict access to specific resources within a webapp, use the servlet-spec defined mechanisms to configure security for the webapp. (Some familiarity with the servlet spec is required before fooling around with a servlet container such as Tomcat.) - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IP based request filters for admin/manager
Thanks for the reply Chuck. I don't want to replace the default ROOT webapp, in other words, I don't want my specific webapp to be ROOT app. But I would like to restrict/hide information normally exposed by the default ROOT webapp. I am thinking about renaming ROOT directory to some other-random-name and restrict access to other-random-name using IP filtering. Any suggestions or comments? Also, an unrelated question to IP filtering, but related manager webapp. I removed 'manager' from webapps directory. Now I am not able to access http://hostname/manager , but http://hostname/manager/html works. I am not following how second link is working? Am I missing anything? Thanks, jM. On Sat, Jul 17, 2010 at 11:30 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Johan Martinez [mailto:jmart...@gmail.com] Subject: IP based request filters for admin/manager How can I deny access to default welcome/index page, changelog, release-notes etc.? If you're deploying Tomcat in any kind of environment that requires securing access to various components, you would normally replace the default webapp (ROOT) with one of your own, thereby eliminating the changelog, release-notes, etc. If you want to restrict access to specific resources within a webapp, use the servlet-spec defined mechanisms to configure security for the webapp. (Some familiarity with the servlet spec is required before fooling around with a servlet container such as Tomcat.) - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: IP based request filters for admin/manager
From: Johan Martinez [mailto:jmart...@gmail.com] Subject: Re: IP based request filters for admin/manager I don't want to replace the default ROOT webapp, in other words, I don't want my specific webapp to be ROOT app. A little odd, but if that's your choice... But I would like to restrict/hide information normally exposed by the default ROOT webapp. All of what Tomcat's default ROOT has, or just some of it? For all of it, just place a Context element in webapps/ROOT/META-INF/context.xml, configuring the valve you already know about. (Do not use path or docBase attributes here - they're not allowed.) If you only want to restrict some of it, but don't want to use authentication, you'll need to write a more sophisticated filter. There's no need to move or rename ROOT, unless you're just trying to obscure things (and security through obscurity is a fool's game). I removed 'manager' from webapps directory. What version of Tomcat are you using? If you're using 5.5.x (hinted at by your previous message's reference to a doc page), the manager webapp is in server/webapps, not the regular webapps directory. If you're using a newer Tomcat (and you probably should be), manager is under the regular webapps directory. Now I am not able to access http://hostname/manager You never could - that will always get you a 404 (at least until Tomcat 7.0.1 comes out). but http://hostname/manager/html works. That's the valid URL for the manager GUI. Looks like you didn't really get rid of it. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
