Re: Tomcat 6.0.18 Caching Question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vasanth, I'm finally getting around to reading all the messages in this thread. I have a few questions: On 11/22/12 10:39 AM, Sekar, Vasanth wrote: Sorry, about that. Here is the detailed explanation. html:options collection=pages property=pageNumber styleClass=textbody/ So you are using Apache Struts. Good to know. Maybe next time tell us that's what's happening. What's in the pages collection? From what scope does that get loaded (page, request, session, or application)? If you are using html:options, it's going to be related to a form bean. Does the form bean know which item should be pre-selected? How? IIRC, Struts takes the form's pageNumber value and if it matches any item in the pages collection, it sets that one to selected. So, during first time access - html view source option value=0 class=textbody0/option option value=1 selected=selected class=textbody1/option option value=2 class=textbody2/option option value=3 class=textbody3/option option value=4 class=textbody4/option option value=5 class=textbody5/option If you notice there is a selected on option value=1 and default option on page load will be selected to option value 1 [...] The selected selected is missing upon future requests. This is how it will be and since selected is not there it would default to first record 0. option value=0 class=textbody0/option option value=1 class=textbody1/option option value=2 class=textbody2/option option value=3 class=textbody3/option option value=4 class=textbody4/option option value=5 class=textbody5/option Sounds like the form bean's pageNumber value is probably null. Perhaps the form bean has been lost? Or reset? Is this a single user navigating to the page (and getting selected=1) then hitting RELOAD and getting no pre-selected item? This question almost certainly has nothing to do with Tomcat, and everything to do with your own webapp/JSP and Struts. We still may be able to help, but you are going to need to provide more information. As for your your ops team, you should tell them to abandon their 7.0.8 testing and piloting: it's a complete and utter waste of their time. Tell them to start over with 7.0.33 or just give up on ever approving another version of Tomcat again because they can't get it done in a reasonable time. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlC36dQACgkQ9CaO5/Lv0PAafACferZTwpDozR1pkPphcNmlbHnA y6MAoJBZACLjppp467NpO4uuNKMp7cjm =7JA/ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.18 Caching Question
On 22 Nov 2012, at 07:15, Sekar, Vasanth vasanth.se...@supervalu.com wrote: Hello- I am working on a project where we are migrating a web app from JRUN 4.0 to Tomcat 6.0 and facing some sort of caching problem with one of the functionality. You refer to Tomcat 6.0.18 in the subject, why would you 'upgrade' to a really old version of Tomcat when 6.0.36 is available with very many important fixes? The same jsp:include code works fine in JRUN server but in Tomcat for the page to work properly I have to clear the cache under work/catalina before accessing the page every time. I thought initially it was some browser cache but that doesn't seem to be the case. Clearing the browser cache did not help and only emptying the contents in work/catalina seems to do the trick. I understand that there is a way to prevent this caching under work/catalina but trying to figure out if there is a way where I can explicitly tell Tomcat to recompile this particular jsp file upon each request. I looked at JRUN to see if it was caching that particular JSP page and even it does it as well. Issue details: We are having a list that populates the data from database. For example: page number field with values 0,1,2,3,4 Ok so far. On first time, it does show the proper page selected value - say 4. Not enough information to understand what this means. Can you post code or explain in more detail please? The next time when we try to access it the selected value does not show up correctly and it just defaults the first record in the drop down - 0. I did view source of the html and see the select tag not present upon future requests. So the entire SELECT form element is missing? When I empty the content in nwork/catalina (no tomcat restart) then it recompiles the file and would show up the proper value. Still pretty vague as to what you are doing... p The same code works fine in JRUN and am trying to figure out how to get this working in Tomcat without having to clear Tomcat cache. If anyone has some thoughts to debug this situation further, please shed some light. Thank you, Regards, Vasanth Sekar - 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 6.0.18 Caching Question
Hi, Please see my inline comments. Thank you, Regards, Vasanth Sekar -Original Message- From: Pid * [mailto:p...@pidster.com] Sent: Thursday, November 22, 2012 1:28 AM To: Tomcat Users List Subject: Re: Tomcat 6.0.18 Caching Question On 22 Nov 2012, at 07:15, Sekar, Vasanth vasanth.se...@supervalu.com wrote: Hello- I am working on a project where we are migrating a web app from JRUN 4.0 to Tomcat 6.0 and facing some sort of caching problem with one of the functionality. You refer to Tomcat 6.0.18 in the subject, why would you 'upgrade' to a really old version of Tomcat when 6.0.36 is available with very many important fixes? That's the standard version that we have inside our environment for Prod move at this point. Tomcat 7.0.8 build is underway but not in our Prod environment yet. So, for now I have to use the current standard version and hence using this particular version 6.0.18. The same jsp:include code works fine in JRUN server but in Tomcat for the page to work properly I have to clear the cache under work/catalina before accessing the page every time. I thought initially it was some browser cache but that doesn't seem to be the case. Clearing the browser cache did not help and only emptying the contents in work/catalina seems to do the trick. I understand that there is a way to prevent this caching under work/catalina but trying to figure out if there is a way where I can explicitly tell Tomcat to recompile this particular jsp file upon each request. I looked at JRUN to see if it was caching that particular JSP page and even it does it as well. Issue details: We are having a list that populates the data from database. For example: page number field with values 0,1,2,3,4 Ok so far. On first time, it does show the proper page selected value - say 4. Not enough information to understand what this means. Can you post code or explain in more detail please? Sorry, about that. Here is the detailed explanation. html:options collection=pages property=pageNumber styleClass=textbody/ So, during first time access - html view source option value=0 class=textbody0/option option value=1 selected=selected class=textbody1/option option value=2 class=textbody2/option option value=3 class=textbody3/option option value=4 class=textbody4/option option value=5 class=textbody5/option If you notice there is a selected on option value=1 and default option on page load will be selected to option value 1 The next time when we try to access it the selected value does not show up correctly and it just defaults the first record in the drop down - 0. I did view source of the html and see the select tag not present upon future requests. So the entire SELECT form element is missing? The selected selected is missing upon future requests. This is how it will be and since selected is not there it would default to first record 0. option value=0 class=textbody0/option option value=1 class=textbody1/option option value=2 class=textbody2/option option value=3 class=textbody3/option option value=4 class=textbody4/option option value=5 class=textbody5/option When I empty the content in nwork/catalina (no tomcat restart) then it recompiles the file and would show up the proper value. Still pretty vague as to what you are doing... I cannot get it show proper selected value on screen until I go to work\Catalina\localhost\ and delete the previous xyz_jsp.java compiled version. I go here and delete this cached file. Then access the same screen again This time it would show up like before. Selected option on option value =1 and will default correctly. Please let me know if you need further inputs or if am still unclear in trying to explain the whole problem. p The same code works fine in JRUN and am trying to figure out how to get this working in Tomcat without having to clear Tomcat cache. If anyone has some thoughts to debug this situation further, please shed some light. Thank you, Regards, Vasanth Sekar - 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 6.0.18 Caching Question
On 22/11/2012 15:39, Sekar, Vasanth wrote: That's the standard version that we have inside our environment for Prod move at this point. Tomcat 7.0.8 build is underway but not in our Prod environment yet. So, for now I have to use the current standard version and hence using this particular version 6.0.18. 6.0.18 and 7.0.8? Have you read the security vulnerability pages? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.18 Caching Question
From: Sekar, Vasanth [mailto:vasanth.se...@supervalu.com] Subject: RE: Tomcat 6.0.18 Caching Question That's the standard version that we have inside our environment for Prod move at this point. Your upgrade strategy is very seriously flawed. Tomcat 7.0.8 build is underway but not in our Prod environment yet. So you're going to upgrade from a four-year-old version to one that's nearly two years old? That is simply irresponsible. - 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: Tomcat 6.0.18 Caching Question
On 22/11/2012 16:29, Mark Thomas wrote: On 22/11/2012 15:39, Sekar, Vasanth wrote: That's the standard version that we have inside our environment for Prod move at this point. Tomcat 7.0.8 build is underway but not in our Prod environment yet. So, for now I have to use the current standard version and hence using this particular version 6.0.18. If the Tomcat 7.x build is still underway, why don't pop over to whoever's desk it is that's doing the work and point out that 7.0.33, (that's *thirty-three* on the end there), is 25 releases after the out of date one that they're planning to install... ? 6.0.18 and 7.0.8? Have you read the security vulnerability pages? Maybe he's emailing us from the year 2008. p -- [key:62590808] signature.asc Description: OpenPGP digital signature
RE: Tomcat 6.0.18 Caching Question
I very well understand the point everyone are trying to make here . But, unfortunately I have to go with the approved version with in our environment. I believe there were also talks about 7.0.26 but it will be quite some time before they pilot everything and approve the version for Prod usage :(. I don't have any authority to change how things work but will for sure bring that concern up to the architect team when I meet with them next time. That being said, any thoughts on the original problem though :) Thank you, Regards, Vasanth Sekar -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Thursday, November 22, 2012 9:50 AM To: Tomcat Users List Subject: Re: Tomcat 6.0.18 Caching Question On 22/11/2012 16:29, Mark Thomas wrote: On 22/11/2012 15:39, Sekar, Vasanth wrote: That's the standard version that we have inside our environment for Prod move at this point. Tomcat 7.0.8 build is underway but not in our Prod environment yet. So, for now I have to use the current standard version and hence using this particular version 6.0.18. If the Tomcat 7.x build is still underway, why don't pop over to whoever's desk it is that's doing the work and point out that 7.0.33, (that's *thirty-three* on the end there), is 25 releases after the out of date one that they're planning to install... ? 6.0.18 and 7.0.8? Have you read the security vulnerability pages? Maybe he's emailing us from the year 2008. p -- [key:62590808] - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.18 Caching Question
I am trying to disable the caching under work/catalina - _jsp.java _jsp.class by doing the following In context added the following cachingAllowed = false parameter Context path=/test docBase=test cachingAllowed=false Deleted the work/catalina cache and restarted the tomcat server. Tired to access the app and _jsp.java _jsp.class showed up again. So, tried the additional following as well In tomcat/conf - context.xml did the following !-- Default set of monitored resources -- WatchedResourceWEB-INF/web.xml/WatchedResource WatchedResourceWEB-INF/classes/WatchedResource In tomcat/conf - web.xml following is the entry servlet servlet-namejsp/servlet-name servlet-classorg.apache.jasper.servlet.JspServlet/servlet-class init-param param-namedevelopment/param-name param-valuefalse/param-value /init-param /servlet Still not able to avoid the Tomcat JSP cache under work/catalina - not entirely sure if I am missing some entries or step here. Please advise. Thank you, Regards, Vasanth Sekar -Original Message- From: Sekar, Vasanth Sent: Thursday, November 22, 2012 12:15 AM To: 'Tomcat Users List' Subject: Tomcat 6.0.18 Caching Question Hello- I am working on a project where we are migrating a web app from JRUN 4.0 to Tomcat 6.0 and facing some sort of caching problem with one of the functionality. The same jsp:include code works fine in JRUN server but in Tomcat for the page to work properly I have to clear the cache under work/catalina before accessing the page every time. I thought initially it was some browser cache but that doesn't seem to be the case. Clearing the browser cache did not help and only emptying the contents in work/catalina seems to do the trick. I understand that there is a way to prevent this caching under work/catalina but trying to figure out if there is a way where I can explicitly tell Tomcat to recompile this particular jsp file upon each request. I looked at JRUN to see if it was caching that particular JSP page and even it does it as well. Issue details: We are having a list that populates the data from database. For example: page number field with values 0,1,2,3,4 On first time, it does show the proper page selected value - say 4. The next time when we try to access it the selected value does not show up correctly and it just defaults the first record in the drop down - 0. I did view source of the html and see the select tag not present upon future requests. When I empty the content in work/catalina (no tomcat restart) then it recompiles the file and would show up the proper value. The same code works fine in JRUN and am trying to figure out how to get this working in Tomcat without having to clear Tomcat cache. If anyone has some thoughts to debug this situation further, please shed some light. Thank you, Regards, Vasanth Sekar - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.18 Caching Question
On Thu, Nov 22, 2012 at 04:49:42PM +, Pid wrote: Have you read the security vulnerability pages? Maybe he's emailing us from the year 2008. Maybe. That said, I am not too keen to see every other question on this list being turned into a question about upgrading. Most of the questions are valid regardless of the used version. Signal to noise, and all that. - Jukka. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.18 Caching Question
From: a b [mailto:jruoh...@gmail.com] On Behalf Of Jukka Ruohonen Subject: Re: Tomcat 6.0.18 Caching Question I am not too keen to see every other question on this list being turned into a question about upgrading. There are two significant reasons for sites to stay up to date on server software such as Tomcat: 1) Critical security issues are published once the fix is available in a released version. By refusing to upgrade, and making public the fact that your site is running an ancient version, one is sending out an invitation to hackers. That's the irresponsibility part. 2) Tomcat support on this mailing list is done by unpaid volunteers. I doubt that any of us have an interest in turning the clock back four years to experiment with a superseded version where the problem (especially ill-described ones, such as this) might well have been fixed somewhere along the way. It would greatly benefit the OP if he at least tried to reproduce the problem on a current version. If the problem is resolved, he would have considerable leverage to get management to approve a true upgrade; if the problem persists, then we now have something more pertinent to go on. - 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: Tomcat 6.0.18 Caching Question
From: Sekar, Vasanth [mailto:vasanth.se...@supervalu.com] Subject: RE: Tomcat 6.0.18 Caching Question I am trying to disable the caching under work/catalina - _jsp.java _jsp.class by doing the following That's not caching; that's where the translated and then compiled JSP are placed as a result of accessing the JSP the first time. In context added the following cachingAllowed = false parameter Please read the description of the cachingAllowed attribute in the Tomcat docs; note that it applies to _static_ resources. Context path=/test docBase=test cachingAllowed=false Unless your Context element is in server.xml (which it shouldn't be), the path attribute is not allowed - but this is not really relevant to your problem, just good practice. Deleted the work/catalina cache and restarted the tomcat server. Tired to access the app and _jsp.java _jsp.class showed up again. Which is how it should be. All you've shown us so far is the HTML as seen by the browser, which is of only minor interest. Pid asked to see the code (that would be the JSP code), which would be much more pertinent. All evidence at the moment indicates that your JSP code is the most likely suspect. And again, at least trying it on a current version would either confirm or eliminate the possibility that the problem has been fixed sometime in the past four years (if it is a Tomcat problem). - 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: Tomcat 6.0.18 Caching Question
All evidence at the moment indicates that your JSP code is the most likely suspect. Okay, I will scan through the logic in the code once again very closely. Like I said before the same code works fine in JRUN and also in Tomcat for the first time. This problem occurs only in Tomcat upon subsequent access. If I get rid of the jsp_java then in work/catalina then it would start working again properly. So, I was under the impression that some kind of a cache problem. And again, at least trying it on a current version would either confirm or eliminate the possibility that the problem has been fixed sometime in the past four years (if it is a Tomcat problem). Sure, I will try to download the latest version and give it a shot to see if the problem manifests in there. Sorry, did not interpret from your original response that you want me to try in latest Tomcat version. I have no problems in doing so and am not against it. It is just that I was trying to explain the reasons for this particular version usage. PS: Hoping that I am not asking any questions on a version that is EOL. Lastly, I am not trying to be irresponsible or willing to post ill-described questions:( Just thought of getting some experts advise here and no other intentions:) 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.18 Caching Question
Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: a b [mailto:jruoh...@gmail.com] On Behalf Of Jukka Ruohonen Subject: Re: Tomcat 6.0.18 Caching Question I am not too keen to see every other question on this list being turned into a question about upgrading. There are two significant reasons for sites to stay up to date on server software such as Tomcat: 1) Critical security issues are published once the fix is available in a released version. By refusing to upgrade, and making public the fact that your site is running an ancient version, one is sending out an invitation to hackers. That's the irresponsibility part. 2) Tomcat support on this mailing list is done by unpaid volunteers. I doubt that any of us have an interest in turning the clock back four years to experiment with a superseded version where the problem (especially ill-described ones, such as this) might well have been fixed somewhere along the way. It would greatly benefit the OP if he at least tried to reproduce the problem on a current version. If the problem is resolved, he would have considerable leverage to get management to approve a true upgrade; if the problem persists, then we now have something more pertinent to go on. +1. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.18 Caching Question
Sekar, Vasanth vasanth.se...@supervalu.com wrote: All evidence at the moment indicates that your JSP code is the most likely suspect. Okay, I will scan through the logic in the code once again very closely. A better idea would be to create the simplest possible JSP that reproduces the issue and then show us the JSP source code. Like I said before the same code works fine in JRUN and also in Tomcat for the first time. This problem occurs only in Tomcat upon subsequent access. If I get rid of the jsp_java then in work/catalina then it would start working again properly. So, I was under the impression that some kind of a cache problem. That sounds more like a JSP source code problem where something is resolved at compile time rather than run time. And again, at least trying it on a current version would either confirm or eliminate the possibility that the problem has been fixed sometime in the past four years (if it is a Tomcat problem). Sure, I will try to download the latest version and give it a shot to see if the problem manifests in there. Sorry, did not interpret from your original response that you want me to try in latest Tomcat version. I have no problems in doing so and am not against it. It is just that I was trying to explain the reasons for this particular version usage. PS: Hoping that I am not asking any questions on a version that is EOL. No, 6.0.x is still supported but if this is a Tomcat bug it will be fixed by another 6.0.x release so you'd have to upgrade anyway. Lastly, I am not trying to be irresponsible or willing to post ill-described questions:( Just thought of getting some experts advise here and no other intentions:) Then you need to provide the information requests - such as the JSP source code. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
