Re: Fix for old SAX issue causing bug 40356
Expressions are evaluated left-to-right in the JSP page. This does not apply when expressions are used in attributes? well, no. however section 1.14 may apply. spec-quote version=2.0 spec=jsp section=1.14 reason=ambiguous The interpretation of all actions start by evaluating the values given to its attributes left to right, and assigning the values to the attributes. /spec-quote A quick search didn't turn up much, but my recolection is that SAX isn't required to be order-preserving on attributes. I have added this info for my (and my colleagues :)) reference to the bug report but won't reopen it unless I run into a clear statement in a SAX or XML spec about order preserving of attributes. I realize I did not get much support for having this fixed, or even have a patch considered if I'd prepare one, but I can't tell my clients so easily that their applications have crazy hacks (unless they go against the Servlet/JSP spec) so please forgive me for trying! Thanks again, Dies - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fix for old SAX issue causing bug 40356
Hello Mark, Thank you, and William Remy for looking at this issue. The JSP in question has several expressions. I thought the following in the JSP 2.0 spec (section JSP.1.12.3) would apply: Expressions are evaluated left-to-right in the JSP page. This does not apply when expressions are used in attributes? #In the next sentence it does go as far as implicitly noting the order within a tag that the expressions are evaluated in, but as I have only one expression per attribute, I think it does not apply. If an expression appears in more than one run-time attribute, they are evaluated left-to-right in the tag. Regards, Dies Mark Thomas wrote: Remy Maucherat wrote: Mark Thomas wrote: Hi, Can anyone remember anything about the SAX bug referred to in this commit? http://marc.theaimsgroup.com/?l=tomcat-devm=105096762802715w=2 No, but there's nothing in the spec which says the attributes have to be called in order. People should avoid crazy hacks, I think :) Indeed. I looked in the spec but couldn't see anything about order either. I'll resolve it as won't fix. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
are JSPs using Java5.0 syntax supported completely?
Hello, I never doubted that Tomcat 5.5 supported JSPs using Java5.0's new syntax and features, until I read the following in the docs: The Java compiler from Eclipse JDT in included as the default compiler. [...] This new compiler will be updated to support the Java 5 syntax as soon as possible. I found it here: http://tomcat.apache.org/tomcat-5.5-doc/jasper-howto.html#Configuration Is this just an old sentence from when Tomcat 5.5 development just started that did not get removed or are there really limitations to the Java 5.0 features you can use in an un-pre-compiled JSP? Thanks, Dies - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TCK Failed Was: Tomcat 5.5.18-beta preview
Hello Filip, In my application I used a pageContext.include which once threw a JasperException (ServletException) while it was supposed to (according to the spec) propagate the IOException as-is. I noticed that setting the deployment init param in conf\web.xml to false made it propagate the IOException correctly. Apparently JspServletWrapper checks this flag and decides to handle exceptions differently depending on this value. I did not look further into it as my problem is resolved, but I have been wondering why it would do this and whether to bring it up here. Regards, Dies Filip Hanik - Dev Lists wrote: Looks like the TCK is expecting a IOException, and not a runtime jasper exception when you have invalid TLD files is one of the errors. --- Test FAILED. Exception thrown by forwardedresource, but was not an instance of IOException Type thrown: org.apache.jasper.JasperException --- ERROR: Exception at: ERROR: com.sun.ts.tests.common.webclient.TestFailureException: Test FAILED! at com.sun.ts.tests.common.webclient.WebTestCase.execute(WebTestCase.java:168) at com.sun.ts.tests.common.webclient.BaseUrlClient.invoke(BaseUrlClient.java:378) at com.sun.ts.tests.jsp.api.javax_servlet.jsp.pagecontext.URLClient.pageContextForwardIOExceptionTest(URLClient.java:166) 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:324) at com.sun.ts.lib.harness.EETest.run(EETest.java:473) at com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:370) at com.sun.ts.lib.harness.EETest.run(EETest.java:229) at com.sun.ts.tests.jsp.api.javax_servlet.jsp.pagecontext.URLClient.main(URLClient.java:26) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: change in session activity tracking between Tomcat 4.1/5.0 and Tomcat 5.5
Hello Jan, Thank you again for your reply. Jan Luehe wrote: I see what you are getting at, and I agree that the servlet spec could be much clearer about this. Unfortunately, this ambiguous wording as been around for the longest time. That is why I was surprised to find the change in Tomcat 5, and no mention in the commit log, Bugzilla or this mailing list that it was misinterpreted and therefore fixed. If the mere presence of a JSESSIONID in the request were considered session access, how would you treat the case where a request did not carry any JSESSIONID, and a servlet created a new session by a call to HttpServletRequest.getSession()? According to your interpretation of SRV.7.6, the session would not be considered accessed until a subsequent request that carried its JSESSIONID was received by the container. Yes, that would also be my interpretation of what the API says: Returns: a long representing the last time the client sent a request associated with this session I would expect it having said something like the following in your interpretation: Returns the last time this session object was accessed, as the number of milliseconds since midnight January 1, 1970 GMT, and marked by the time the container received the request. or Returns: a long representing the last time the session object was accessed I don't believe this was the original spec authors' intention. I will double-check with the Servlet EG to make sure we're all in agreement on this. I suppose they changed their minds a few times on what this method should do and that led to the ambiguity. Thank you for double-checking, I'm looking forward to hearing their reply. Regards, Dies Koper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
change in session activity tracking between Tomcat 4.1/5.0 and Tomcat 5.5
Hello, I'm looking into an issue we ran into when upgrading from Tomcat 4.1 to Tomcat 5.5. The time returned by the HttpSession.getLastAccessTime method seems to have changed. We believe it should return the time of the previous request from the same client. It did in Tomcat 4.1. It did so no matter whether that client accessed a Servlet or an html file. However, in Tomcat 5.5 it only returns this time if the previous request went to a servlet, and that servlet called the getSession or request.encodeURL method. Otherwise it returns the time of the last request from that client that did call either of those methods. I am a bit confused why. Did the Tomcat developers disagree with the Servlet spec or the interpretation of it at the time Tomcat 4.1 was released and is this now fixed? Or is it an accidental side-effect of another change? The reason I ask is because I need to solve this problem. Should I look for a work-around or try to write a patch? So far, I found that the change happened in Tomcat 5.0, with the following commit. Revision: 302627 Author: remm Date: 3:21:36, 2004-01-23 Message: - Improvements to session activity tracking, handling the case where the session is new, as well as cross context. - If this doesn't work, I give up ;) Modified : /tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java Modified : /tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java Modified : /tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/core/StandardHostValve.java Modified : /tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/session/StandardSession.java Thanks, Dies - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: change in session activity tracking between Tomcat 4.1/5.0 and Tomcat 5.5
Hello Jan, Thank you for your reply. Yes, I noticed the associated with this session. It seemed clear. But then I read the following in the specification: [Servlet 2.4 spec - SRV.7.6 Last Accessed Times] The session is considered to be accessed when a request that is part of the session is first handled by the servlet container. I noticed request that is part of the session. Is a request with a jsessionid that gets accepted by the container part of a session? I'd say yes. But you say it is not, until the servlet calls a method that needs to access the session context (getSession, encodeURL, etc.), only then you can say it actually was part of the session? I suppose that does sounds reasonable. I think this change was made to bring the impl in compliance with the servlet spec. The servlet 2.3 spec contains the same. So Tomcat 4.1 does not but Tomcat 5.0/5.5 now does comply with the spec regarding this method? #I had opened a bug about this last month, I'd like to add this info to it for reference before it is closed. Just to make sure, you /think/ this change was done because you have some recollection of it or guessing from what I wrote and what the spec writes? I tried searching the mailing lists about it but could not find any discussion about it. Thank again for the reply, Dies Jan Luehe wrote: Hi Dies, Dies Koper wrote On 08/16/06 05:28,: Hello, I'm looking into an issue we ran into when upgrading from Tomcat 4.1 to Tomcat 5.5. The time returned by the HttpSession.getLastAccessTime method seems to have changed. We believe it should return the time of the previous request from the same client. It did in Tomcat 4.1. It did so no matter whether that client accessed a Servlet or an html file. However, in Tomcat 5.5 it only returns this time if the previous request went to a servlet, and that servlet called the getSession or request.encodeURL method. Otherwise it returns the time of the last request from that client that did call either of those methods. I think this change was made to bring the impl in compliance with the servlet spec. The javadocs of HttpSession.getLastAccessedTime() have this: * Returns the last time the client sent a request associated with * this session, as the number of milliseconds since midnight * January 1, 1970 GMT, and marked by the time the container received the * request. Notice the associated with this session. Only if a request creates or resumes a session should the session's lastAccessedTime be updated. Jan I am a bit confused why. Did the Tomcat developers disagree with the Servlet spec or the interpretation of it at the time Tomcat 4.1 was released and is this now fixed? Or is it an accidental side-effect of another change? The reason I ask is because I need to solve this problem. Should I look for a work-around or try to write a patch? So far, I found that the change happened in Tomcat 5.0, with the following commit. Revision: 302627 Author: remm Date: 3:21:36, 2004-01-23 Message: - Improvements to session activity tracking, handling the case where the session is new, as well as cross context. - If this doesn't work, I give up ;) Modified : /tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java Modified : /tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java Modified : /tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/core/StandardHostValve.java Modified : /tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/session/StandardSession.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: PermGen overflow
Hello Nikita, I only recently joined this list so I might have missed your first message (actually I subscribed that same day). I think what you wrote should help. If you are going to try it out, please let us know the result. Other than that, all I can think of to decrease heap space is to try to move classes that are shared among different web apps to common/lib (parent classloader) so that they are loaded only once. Good luck! Dies Nikita Belov wrote: Why are you ignoring me? Am I state my question so incomprehensible or is my English so bad? -- Nikita -Original Message- From: Nikita Belov [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 26, 2006 6:58 PM To: 'Tomcat Developers List' Subject: PermGen overflow Hello all, I am sorry, I need ask help here, but I already have post this issue to 'Tomcat Users List' and was redirected to this list. I use JBoss 4.0.3sp1 (with embedded Tomcat 5.5) and have problem with JVM PermGen overflow. My application allows user to deploy custom JSP pages to server. These JSP pages copied inside one web-app without its redeploying. After several days of the system work, classes of the compiled JSP pages overflow Java PermGen space. It is needed to drop all references to classloader, to allow GC to finalize classloader and free PermGen from classes loaded by it. But Tomcat drop references to classloader only when web-application undeployed. To resolve this issue I have decide to replace JSP servlet (servlet mapped to *.jsp) with my own implementation. My JSP servlet will call JSP-compiler and load each compiled class by separate classloader instance, which won't be references from anywhere. This will allow GC to remove classloader and free PermGen. I think this will help. Am I right? By the way, is there any easier solution for described problem? All comments are welcome. -- Nikita PS1: I know, PermGen size can be increased with JVM option -XX:PermSize. It helps, but it doesn't solve problem completely. PS2: Deploying custom JSP pages by user is the primary design of my system and can't be changed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
