Re: [ANN] Apache Tomcat 7.0.11 released
On 11/03/2011 19:17, David Calavera wrote: Hi Mark, could you remember to release the maven artifacts, I've seen the last version released was 7.0.8. 7.0.11 Maven deploy started now. It'll take a couple of hours to complete and it'll need to sync to Maven central. I've never checked just how fast that happens but I'd be surprised if it took more than 24 hours. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5.5.30 and Spring Framework
Aureliusz R. wrote: Borut, thanks again. You were correct, it was lazy initialization. Pretty much at this point I got the spring part working. I've encountered yet another issue with mapping requests from apache2 web server to tomcat. It seems to have something to do with SSL, as I don't have this issue for http. The situation looks as follows: The docBase for my app is /usr/local/jsp/ I've placed my spring test JSP in /usr/local/jsp/testSpring/testSpring.jsp apache2/httpd.conf has the following mod_jk mappings: JkMount /servlet/* worker1 JkMount /*.jsp worker1 JkMount /jsp/* worker1 When I invoke this JSP directly through tomcat, or through apache httpd server but over http, it works fine: http://server.domain.com:8080/jsp/testSpring/testSpring.htm http://server.domain.com/jsp/testSpring/testSpring.htm When I invoke this JSP through apache httpd over https, it's actually looking for the static htm file. It doesn't go through tomcat at all. https://server.domain.com/jsp/testSpring/testSpring.htm Not Found The requested URL /jsp/testSpring/testSpring.htm was not found on this server. Would you be able to point me in the right direction? I searched through some of the ssl config files, but I didn't find anything that would prevent /jsp/**/*.htm requests from being sent to tomcat. Under Apache httpd, you cannot have the same server (aka VirtualHost) answering both http and https requests. So you must have at least 2 distinct VirtualHosts, one for http (*:80 ?), one for https (*:443 ?). My guess is that in the https one, you simply do not have the same JkMount directives. Maybe you forgot a JkMountCopy on ? Not actually seeing your httpd.conf makes this a bit of guesswork though. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5.5.30 and Spring Framework
The docBase for my app is /usr/local/jsp/ I've placed my spring test JSP in /usr/local/jsp/testSpring/testSpring.jsp You probably want your's app docBase to be something like /usr/local/myapp, and then have your jsp's in a directory /usr/local/myapp/WEB-INF/jsp/ - eg. /usr/local/myapp/WEB-INF/jsp/testSpring/testSpring.jsp On Sat, Mar 12, 2011 at 5:42 AM, Aureliusz R. aremp...@gmail.com wrote: Borut, thanks again. You were correct, it was lazy initialization. Pretty much at this point I got the spring part working. I've encountered yet another issue with mapping requests from apache2 web server to tomcat. It seems to have something to do with SSL, as I don't have this issue for http. The situation looks as follows: apache2/httpd.conf has the following mod_jk mappings: JkMount /servlet/* worker1 JkMount /*.jsp worker1 JkMount /jsp/* worker1 When I invoke this JSP directly through tomcat, or through apache httpd server but over http, it works fine: http://server.domain.com:8080/jsp/testSpring/testSpring.htm http://server.domain.com/jsp/testSpring/testSpring.htm When I invoke this JSP through apache httpd over https, it's actually looking for the static htm file. It doesn't go through tomcat at all. https://server.domain.com/jsp/testSpring/testSpring.htm Not Found The requested URL /jsp/testSpring/testSpring.htm was not found on this server. Would you be able to point me in the right direction? I searched through some of the ssl config files, but I didn't find anything that would prevent /jsp/**/*.htm requests from being sent to tomcat. Thanks, aurir_ On Fri, Mar 11, 2011 at 9:30 AM, Borut Hadžialić borut.hadzia...@gmail.com wrote: Do not put anything in $TOMCAT_HOME/conf/web.xml - leave that file as it is when you unpack a fresh Tomcat distribution. Why the servlet is not being loaded? - not 100% about this, but I would first check if it is maybe being lazy loaded/initialized. After your tomcat starts up, try to browse http://localhost:8080/test.htm - that http request will be mapped to your spring servlet, and it will trigger the initialization of your spring servlet (if that was the problem in the first place, but i think it is). The exception you were getting meant that your DispatcherServlet couldn't find and load its configuration file at startup. A DispatcherServlet's configuration file is by default /WEB-INF/servlet-name-servlet.xml'. servlet-name is 'spring' in your case - that is how you named it inside web.xml: servlet servlet-namespring/servlet-name /servlet So your DispatcherServlet instance that you named 'spring' tried to load the file /WEB-INF/spring-servlet.xml, which wasn't there and you got the exception: java.io.FileNotFoundException: Could not open ServletContext resource [/WEB-INF/spring-servlet.xml] Make sure you have 'spring' DispatcherServlet's configuration in a file /WEB-INF/spring-servlet.xml, or use some other file with configuration like this: servlet servlet-namespring/servlet-name servlet-class org.springframework.web.servlet.DispatcherServlet /servlet-class init-param param-namecontextConfigLocation/param-name param-value/WEB-INF/foo/bar-servlet.xml/param-value /init-param load-on-startup1/load-on-startup /servlet On Fri, Mar 11, 2011 at 4:08 PM, Aureliusz R. aremp...@gmail.com wrote: Borut, your instructions were spot on. I was able to track down my docBase folder (it was specified in $TOMCAT_HOME/conf/servlet.xml context, and I verified that it's the correct location by adding some context parameters to the web.xml in my docBase, and then retrieving them from a JSP. Now I have another problem though. For some reason, my DispatcherSetvlet (for the spring framework) is not being loaded at all. I tried placing the piece of XML below in the $TOMCAT_HOME/conf/web.xml and my docBase/WEB-INF/web.xml. I also specified invalid fully qualified name for my DispatcherServlet to get some kind of exception, but I don't get anything. Is there anything that would prevent this servlet from being loaded? servlet-mapping servlet-namespring/servlet-name url-pattern*.htm/url-pattern /servlet-mapping It's ridiculous because some time ago when I placed it in $TOMCAT_HOME/conf/web.xml I was getting the exception below, and that's the reason why I wanted to know where my docBase is in the first place. Now that I know where it is, the DispatcherServlet doesn't seem to be loaded at all. Is there anything that would prevent this servlet from being loaded? org.springframework.beans.factory.BeanDefinitionSt oreException: IOException parsing XML document from ServletContext resource [/WEB-INF/spring-servlet.xml]; nested exception is java.io.FileNotFoundException: Could not open ServletContext resource [/WEB-INF/spring-servlet.xml] Thanks, Aurir_ On Tue, Mar 8, 2011 at 2:47 AM, Borut Hadžialić
Re: Performance 5.5 vs 6 vs 7
I've thought about that, but I would think I would be maxing out the cpu if tomcat's processing were the limit. I'm running only about 8% cpu usage across all 4 cpu's. On 3/11/2011 4:23 PM, Tony Anecito wrote: Hi David, I recently ran performance tests against version 7 and during that whole process discovered at best for a single instance of Tomcat 7 running on a 6 core AMD 2.8Ghz processor the best I could get running the client on the server and using loopback network (Localhost) was around 32K per second hitting a servlet that had no code. I was using APR also. By adding the network domain name where it forced the requests to go through my gaming router I could only get 2.2K requests per second. If I ran the client from a laptop on the lan I got around the same number. I have not looked into adding another instance of Tomcat but I suspect as you add latency and some form of code in a servlet it might get down to 100 requests per second. Remember if a single request takes 10msec at Tomcat and depending upon the amount of data and latency (say 100msec) you are already down to 100 req per second at best. You might only get that at best. Regards, -Tony - Original Message From: David kerberdcker...@verizon.net To: Tomcat Users Listusers@tomcat.apache.org Sent: Fri, March 11, 2011 1:02:12 PM Subject: Performance 5.5 vs 6 vs 7 How might I expect the performance of 7 to compare to a late rev of 5.5 or 6.0.x, running under JRE 6? Specifically, my application has lots of small, simple requests, and the app does nothing but de-obfuscate (it's not really sophisticated enough to call it encryption) the data and save it to disk. But it does a LOT of them, 60 to 100 per second during normal operation, more during very busy times. The overall average when I checked last week was about 60 requests per second for the previous 10 days, around the clock,4.5M per day. I spent quite a bit of effort in optimizing my app last year, and got some big gains in it, but now I'm again starting to not be able to keep up with the increased flow as our customer has doubled their number of installations, so I'm looking elsewhere for potential improvements. I've already checked my connection bandwidth, and that still has some headroom, though not a lot. Can I expect TC 6 or 7 to handle larger numbers of very simple requests than 5.5 can? Dave - 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: JSP class size increase in Tomcat 7
On 3/11/2011 6:04 AM, Jess Holle wrote:
On 3/11/2011 3:22 AM, Mark Thomas wrote:
The obvious difference is that Tomcat 6 compilation targets Java 5
whereas Tomcat 7 targets Java 6. For a simple test JSP:
Tomcat 6 (1.5) - 3,488
Tomcat 7 (1.5) - 3,530 +1%
Tomcat 7 (1.6) - 3,668 +6%
The 1% will be a combination of:
- Tomcat 7 uses version 3.6 of the Eclipse compiler while Tomcat 6 uses
3.3.1.
- the source code differences you can see in the .java files.
Hmm
I tried forcing 1.5 as the source/target version for JspC -- I'm still
over 65K with Tomcat 7.
I wonder if there's enough extra hidden code generated by use of
generics...
Anyway, I guess the page owners will have to try to clean things up.
Is it possible that the source/target version is being ignored, e.g. for
the Ant task form of JspC?
I ask as javac fails to compile the Java code generated by jasper as
well for the same reason -- the _jspService method is too big. When I
force 1.5 as the target and source version, however, javac compiles the
generated Java code just fine.
When I try the same trick with my precompilation Ant script, however, ala
jasper2 uriroot=${docBaseLocation}
classpath=${wcWebAppClasspathAsString}
compile=true outputDir=${outputDir}
classDebugInfo=true smapSuppressed=${smapSuppressed}
compilerSourceVM=1.5 compilerTargetVM=1.5
validateXml=false listErrors=true
verbose=${jspcVerbosityLevel} jspFiles=${jspFileList}/
I still get the same failure, which seems rather odd. You'd think that
JDT/EJC can't be generating that much larger code than javac.
--
Jess Holle
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JSP class size increase in Tomcat 7
Nevermind -- I examined other classes produced with 1.5 specified.
These were compiled for 1.5 (version 49.0 byte code).
On another ugly JSP, I note:
* Tomcat 6 - JDT targeting 1.5: 93K
* Tomcat 7 - JDT targeting 1.6: 149K
* Tomcat 7 - JDT targeting 1.5: 133K
* Tomcat 7 - javac (externally from command line) targeting 1.6: 118K
* Tomcat 7 - javac (externally from command line) targeting 1.5: 68K
* Tomcat 7 - JDT targeting 1.5 with debug off and smap suppressed: 68K
Clearly there's normally extra expense for debug/smap information,
though it's not clear to me whether this works against the 65K limit or not.
Note the last 2 results are essentially identical (I didn't compare byte
counts).
Yet when I try this last configuration with the JSP that goes over 65K
it fails with JDT and succeeds with javac.
--
Jess Holle
On 3/12/2011 9:50 AM, Jess Holle wrote:
On 3/11/2011 6:04 AM, Jess Holle wrote:
On 3/11/2011 3:22 AM, Mark Thomas wrote:
The obvious difference is that Tomcat 6 compilation targets Java 5
whereas Tomcat 7 targets Java 6. For a simple test JSP:
Tomcat 6 (1.5) - 3,488
Tomcat 7 (1.5) - 3,530 +1%
Tomcat 7 (1.6) - 3,668 +6%
The 1% will be a combination of:
- Tomcat 7 uses version 3.6 of the Eclipse compiler while Tomcat 6 uses
3.3.1.
- the source code differences you can see in the .java files.
Hmm
I tried forcing 1.5 as the source/target version for JspC -- I'm
still over 65K with Tomcat 7.
I wonder if there's enough extra hidden code generated by use of
generics...
Anyway, I guess the page owners will have to try to clean things up.
Is it possible that the source/target version is being ignored, e.g.
for the Ant task form of JspC?
I ask as javac fails to compile the Java code generated by jasper as
well for the same reason -- the _jspService method is too big. When I
force 1.5 as the target and source version, however, javac compiles
the generated Java code just fine.
When I try the same trick with my precompilation Ant script, however, ala
jasper2 uriroot=${docBaseLocation}
classpath=${wcWebAppClasspathAsString}
compile=true outputDir=${outputDir}
classDebugInfo=true smapSuppressed=${smapSuppressed}
compilerSourceVM=1.5 compilerTargetVM=1.5
validateXml=false listErrors=true
verbose=${jspcVerbosityLevel} jspFiles=${jspFileList}/
I still get the same failure, which seems rather odd. You'd think
that JDT/EJC can't be generating that much larger code than javac.
--
Jess Holle
Re: Performance 5.5 vs 6 vs 7
On 11 March 2011 20:02, David kerber dcker...@verizon.net wrote: I've already checked my connection bandwidth, and that still has some headroom, though not a lot. What's not a lot? If latency across the connection is starting to increase due to congestion, that could increase the time to process requests, therefore increase the number of requests still active, therefore consume more resources on the server. Also, what is the connection and what's upstream of it? Might upstream congestion be an issue? - Peter
WebDav Configuration Question
I'm running Tomcat 6.0.24 on Ubuntu 10.04.2 LTS. I'm trying to configure WebDav and limit access to a single folder, a subdirectory of my applications www folder... i.e. www/myapp/subdir. I want to limit access only to subdir and disable the clients ability to create any new directories. I've perused all config info that I found but was unclear on either point. I've added the following to the applications web.xml and WebDav works however, the client can create new directories and they're currently landing in my www/myapp folder (where all html, jsp, js, etc. files are located). Any assistance/direction appreciated. servlet servlet-namewebdav/servlet-name servlet-classorg.apache.catalina.servlets.WebdavServlet/servlet-class init-param param-namedebug/param-name param-value0/param-value /init-param init-param param-namelistings/param-name param-valuetrue/param-value /init-param init-param param-namereadonly/param-name param-valuefalse/param-value /init-param /servlet servlet-mapping servlet-namewebdav/servlet-name url-pattern/webdav/*/url-pattern /servlet-mapping security-constraint web-resource-collection web-resource-nameWebDav Login Resources/web-resource-name url-pattern/webdav/*/url-pattern /web-resource-collection auth-constraint role-nametomcat/role-name /auth-constraint /security-constraint login-config auth-methodBASIC/auth-method realm-namedefault/realm-name /login-config security-role role-nametomcat/role-name /security-role -- Scott Dudley Senior Developer Telesoft Corp. | 1661 E. Camelback Rd., Suite 300 | Phoenix, AZ, 85016 *o:* (602) 308-1115**| *f:* (602) 308-1300 | *w:* www.telesoft.com http://www.telesoft.com
Re: Fastest way to upgrade from 7.0.10 to 7.0.11?
Hi Mark, Thanks a lot for your response. I did agree with Charles regarding the usually bad idea about just replacing JARs, but in this specific case (7.0.10 to 7.0.11) I suspected it could be done just replacing JARs. I will try it definitely. On Fri, Mar 11, 2011 at 12:40 PM, Mark Thomas ma...@apache.org wrote: On 11/03/2011 17:21, Caldarale, Charles R wrote: From: Brian Braun [mailto:brianbr...@gmail.com] Subject: Fastest way to upgrade from 7.0.10 to 7.0.11? I wouldn't like to uninstall the whole software and install 7.0.11 from scratch. I would like to stop it, replace some files (some JARs, I guess), and start it again. Wrong approach. Always install a new version of Tomcat in a separate directory, update the new server.xml with your site-specific information (do not blindly copy the old server.xml over), and copy your webapps over to the new appBase. If you keep your webapps outside of Tomcat's directory structure, then the last step is not necessary. The simplest way is to use a separate CATALINA_HOME and CATALINA_BASE. Upgrades take just a few minutes with that approach. In the specific case of 7.0.10 to 7.0.11 you should be able to just replace the JAR files. - Stop 7.0.10 - Replace all the JAR files (and the docs webapp) - Empty the work directory - Start Tomcat This only works because of the very few changes between 7.0.10 and 7.0.11. Normally, this approach would bring all sorts of problems. The caveat is that this is untested and you may end up with a non-functioning Tomcat instance. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Migrated from 6.0.29 to 7.0.10, Now I get INFO: TLD skipped. URI: http://struts.apache.org/tags-bean is already defined
Well, first of all, I'm using the 2004 Struts version. Why didn't I upgraded that over all these years? Because in the first years I thought I was going to migrate to JSF, and recetly I'm thinking that maybe I should go with Spring. For that reason, I didn't want to invest time upgrading to the most recent versions of Struts, and I got stuck on time. I usually adopt new version early (as I have done with Struts 7.0.11), but with Struts... that happened. I Still haven't decided between JSF and Spring. I know they are not the same thing, that Spring brings more that a presentation and controller, but in the presentation area I don't know if I should go with JSF (which is the new standard, right?), or with Spring's MVC. But certainly I'm obsolete using 2004's Struts. On Fri, Mar 11, 2011 at 5:39 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian, On 3/9/2011 3:42 PM, Brian Braun wrote: Actually, I had already unzipped my .war file and inspected every file inside, and arrived to that conclution: The only place where the TLD files are also present is the JARs that correspond to Struts (don't laugh, but I'm still using it) and other components. Why would anyone laugh that you are using Struts? I think it's a great framework, and it's still maintained by a dedicated group of people. Would you prefer something else? Or, does Struts just have a long enough history to make it un-cool? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk16pIsACgkQ9CaO5/Lv0PAbEQCgl3JHfnkXpx0h1TYaAalJkWty 0SwAnRvOjKTjagdLGMhN/IIz1P8XuXTT =NQKX -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: StackOverFlowError in Tomcat 6.0.29
2011/3/12 Christopher Schultz ch...@christopherschultz.net: https://issues.apache.org/bugzilla/show_bug.cgi?id=50883 - From your bug report, this stack trace does not look right at all (...) - From that stack trace, it appears that ApplicationHttpRequest.setAttribute is calling HttpServlet.service which would be very surprising. It would be good to know what filters you have running and what wrappers are being added to the request. I agree that the stack trace does look suspicious. My suspicion is that there is a loop of forwards being done by that filter, (...) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302) at com.kony.web.controller.KonyBaseServlet.navigateToNextForm(Unknown Source) Each doForward() wraps the request once. So, after a thousand of forwards you have a long chain of thousand requests, on which you are calling that setAttribute() method. Thus, there is no wonder that that method is mentioned on the stack trace a thousand times. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Migrated from 6.0.29 to 7.0.10, Now I get INFO: TLD skipped. URI: http://struts.apache.org/tags-bean is already defined
Hi Mark, I have been thinking about this issue, and I have some thoughts and questions. My web.xml file doesn't mention the TLDs, but I have confirmed that the Struts JAR does contain them. That is the reduncancy. I tried removing the TLDs from my WEB-INF directory, and the the info message was not being show anymore, which is nice and was my goal. However, my app fails as soon as one of the pages with a %@ taglib directive refers to the deleted TLD file, for example one of my pages does this: %@ taglib uri=*/WEB-INF/struts-bean.tld* prefix=*bean*% That page fails, because it is not being able to find the TLD file anymore. What should I do? I really want to get rid of the info messages. - Do I need to delete the TLDs from my WEB-INF directory? That makes my JSPs fail. - Do I need to modify the taglib directives, so they refer to the TLD files inside the JAR or something like that? - Do I need to delete the TLD files from the Struts JAR? That wouldn't sound OK to me, one should not modify a JAR that comes from a components such as Struts. - Should I tell Tomcat not to show those info messages somehow? TIA, Brian On Wed, Mar 9, 2011 at 1:16 PM, Mark Thomas ma...@apache.org wrote: On 09/03/2011 18:12, Brian Braun wrote: Hi, I just migrated from Tomcat 6.0.29 to 7.0.10. I have solved several problems regarding the migration, but I don't know what these mean: INFO: Deploying web application archive ROOT.war Mar 9, 2011 9:28:12 AM org.apache.catalina.startup.TaglibUriRule body INFO: TLD skipped. URI: http://struts.apache.org/tags-bean is already defined Mar 9, 2011 9:28:12 AM org.apache.catalina.startup.TaglibUriRule body INFO: TLD skipped. URI: http://struts.apache.org/tags-html is already defined Mar 9, 2011 9:28:12 AM org.apache.catalina.startup.TaglibUriRule body INFO: TLD skipped. URI: http://struts.apache.org/tags-logic is already defined Mar 9, 2011 9:28:12 AM org.apache.catalina.startup.TaglibUriRule body INFO: TLD skipped. URI: http://struts.apache.org/tags-nested is already defined Mar 9, 2011 9:28:12 AM org.apache.catalina.startup.TaglibUriRule body INFO: TLD skipped. URI: http://struts.apache.org/tags-tiles is already defined Mar 9, 2011 9:28:12 AM org.apache.catalina.startup.TaglibUriRule body INFO: TLD skipped. URI: http://displaytag.sf.net is already defined Something tells me that Tomcat now expects my web.xml file to comply with the new Servlet/JSP specifications, or a new version of the web.xml format. I haven't changed my web.xml file at all, yet. I would like to get rid of these warnings. Anybody knows what is this about? They are INFO messages so do not indicate an error condition. It looks like you have multiple TLD definitions for a given URI (web.xml and TLD embedded in a JAR?). Removing the duplicates should fix it. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
