Re: Session Config = Tracking Mode not working
Hello Konstantin Kolinko, I fixed my dumb web.xml schema declaration. Thanks for pointing that out. I also added the COOKIE tracking mode to the example servlet and it worked there (the URL encoded link did not contain the JSESSIONID). So, next I turned on logEffectiveWebXml=true and verified that the effective web.xml for both of my wars contains: session-config session-timeout30/session-timeout cookie-config /cookie-config tracking-modeCOOKIE/tracking-mode /session-config But the first time I hit the web app, I'm still getting JSESSIONID in the URL. Then I turned on Strict Compliance to wring out any other errors in my web.xml that might be causing the problem. It found some problems in the Tag Library tld files and fixed those, but that had no effect on JSESSIONID in the URL. I have no further errors in Catalina log or any other logs files. At this point, I'm not sure what else I should try to debug the problem. Any suggestions would be appreciated. Sincerely, Stephen McCants On Tue, 18 Nov 2014 03:17:27 +0300 Konstantin Kolinko knst.koli...@gmail.com wrote: 2014-11-18 2:49 GMT+03:00 Stephen McCants stephen.mcca...@hcs.us.com: Hello, I'm trying to remove the JSESSIONID from my URL the first time someone hits my Tomcat Web App, but I've not been able to get it working for some reason that eludes me. This is under Tomcat 7.0.37 and Tomcat 7.0.56. First thing I tried was to add session-config/tracking mode to my web.xml, resulting in: ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app 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-app_3_0.xsd; version=3.0 You are declaring both 2.3 DTD and 3.0 schema. Choose one. There exists a system property that turns on strict servlet compliance mode. If you use it, it enables validation of your web.xml and will catch silly errors like this one. http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Specification session-config tracking-modeCOOKIE/tracking-mode /session-config If I add the above three lines to the web.xml of examples webapp, it works for me. http://localhost:8080/examples/servlets/servlet/SessionExample On the first visit to that example page look at URL encoded link at the bottom of the page, whether it contains jsessionid in it or not. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Stephen McCants Senior Software Engineer Healthcare Control Systems, Inc. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: isELIgnored default is wrong
Hello Konstantin Kolinko, Thank you for the useful debugging tips. By setting the server in Strict Compliance, I found some problems with our TLD declarations. After fixing that, isELIgnored has the default of true, as expected. Thanks again! Sincerely, Stephen McCants On Sat, 8 Nov 2014 17:08:46 +0300 Konstantin Kolinko knst.koli...@gmail.com wrote: I worked around the problem by adding the following to the JSP files: %@ page isELIgnored=false % However, I'd like to understand where the configuration error is occurring as from my perspective nothing changed except OS and Tomcat version. My own efforts have turned up nothing helpful or illuminating. Where should I be looking in the configurations for a difference? What differences would come into play? What is your tag library declaration in your JSP file? That's probably the most important thing, here. Are you supplying your own version of JSTL, EL, etc. along with your web application? +1. There have been several user reports when Apache Maven packed conflicting API implementation jars into a war file. I do not remember it resulting in such symptoms, but things were going awry for those affected. I would suggest trying the following: 1) Add logEffectiveWebXml=true to your Context and see how that web.xml is actually interpreted by Tomcat (considering all web fragments and annotations) http://tomcat.apache.org/tomcat-7.0-doc/config/context.html 2) Run in strict servlet compliance mode. That will enable validation of your web.xml against schema. http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Specification 3) Are there any errors, warnings in the log files? If that does not help, then maybe a) inspect the java code generated for your JSPs b) run with a debugger https://wiki.apache.org/tomcat/FAQ/Developing#Debugging c) try with 7.0.42 on Windows, and then with intermediate versions up to 7.0.56 to see when the problem appeared. d) test with 7.0.57 (a release candidate is currently in the voting process on dev@) e) simplify your web application until you have a reproducible test case that you can show others The examples webapp has EL on its pages and those are certainly working. f) update you web.xml to version 3.0 and configure it to avoid annotation scanning https://wiki.apache.org/tomcat/HowTo/FasterStartUp Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Stephen McCants Senior Software Engineer Healthcare Control Systems, Inc. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session Config = Tracking Mode not working
Spent sometime in the debugger and it is Shiro that is appending the JSESSIONID on a redirect if the session cookie hasn't been set yet. So, now I'm off to figure out how to turn it off in Shiro. Thanks again for your help! Sincerely, Stephen McCants On Wed, 19 Nov 2014 01:51:53 +0300 Konstantin Kolinko knst.koli...@gmail.com wrote: 2014-11-19 0:53 GMT+03:00 Konstantin Kolinko knst.koli...@gmail.com: 2014-11-19 0:21 GMT+03:00 Stephen McCants stephen.mcca...@hcs.us.com: Hello Konstantin Kolinko, I fixed my dumb web.xml schema declaration. Thanks for pointing that out. I also added the COOKIE tracking mode to the example servlet and it worked there (the URL encoded link did not contain the JSESSIONID). So, next I turned on logEffectiveWebXml=true and verified that the effective web.xml for both of my wars contains: session-config session-timeout30/session-timeout cookie-config /cookie-config tracking-modeCOOKIE/tracking-mode /session-config But the first time I hit the web app, I'm still getting JSESSIONID in the URL. Then I turned on Strict Compliance to wring out any other errors in my web.xml that might be causing the problem. It found some problems in the Tag Library tld files and fixed those, but that had no effect on JSESSIONID in the URL. I have no further errors in Catalina log or any other logs files. At this point, I'm not sure what else I should try to debug the problem. Any suggestions would be appreciated. a) Run with a debugger https://wiki.apache.org/tomcat/FAQ/Developing#Debugging Possible points: org.apache.catalina.connector.Response.encodeURL() org.apache.catalina.connector.Response.encodeRedirectURL() org.apache.catalina.connector.CoyoteAdapter.service() Also: org.apache.catalina.session.StandardSession.getId(). It is the actual Id that is being printed as jsessionid there. It shall be read using that method. If debugging is hard, adding some logging with some stacktraces and recompiling can help. b) Simplify your web application until it becomes a simple example that can be reproduced by someone else. c) But the first time I hit the web app Is that first time response actually served by your web app, or by some other (e.g. ROOT)? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Stephen McCants Senior Software Engineer Healthcare Control Systems, Inc. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Session Config = Tracking Mode not working
Hello, I'm trying to remove the JSESSIONID from my URL the first time someone hits my Tomcat Web App, but I've not been able to get it working for some reason that eludes me. This is under Tomcat 7.0.37 and Tomcat 7.0.56. First thing I tried was to add session-config/tracking mode to my web.xml, resulting in: ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app 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-app_3_0.xsd; version=3.0 session-config tracking-modeCOOKIE/tracking-mode /session-config However, that didn't seem to have any effect, so next I setting it in the default /conf/web.xml: session-config session-timeout30/session-timeout !-- Disable writing the session cookie on the URL -- tracking-modeCOOKIE/tracking-mode /session-config This to had no effect. I also found no error messages in the logs and didn't turn up anything helpful on Google, so I'm at a loss as to why this isn't working. On our production server, we are using mod_rewrite and Apache to strip it out of the URL, so the user never sees it, but I'm needing to do some testing on a local system and would rather not have the complication of Apache present. Some of the software running tests is getting confused by the JSESSIONID on the URL the first time it hits our login page, so it doesn't recognize the login page. Thoughts as to where I might have gone wrong? Thanks in advance. Sincerely, Stephen -- Stephen McCants Senior Software Engineer Healthcare Control Systems, Inc. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: isELIgnored default is wrong
Hello Christopher Schultz,
Sorry for the delayed reply.
On 11/7/14 2:51 PM, Stephen McCants wrote:
I'm seeing a strange problem where isELIgnored has the wrong
default value for a new Tomcat install of 5.0.56.
That version number is certainly wrong.
Highest 5.0 version is 5.0.30
Highest 5.5 version is 5.5.36
Hopefully, you meant Tomcat 7.0.56 which is the most current release
of Tomcat 7.0.
Sorry, typo. 7.0.56 is correct.
I'm moving a Web Application on Windows 7 to Windows 2008 and that
caused the EL expressions to stop being evaluated on the new
install..
Problem is only seen on Windows Server 2008 with Tomcat 7.0.56,
while it works correctly on Tomcat 7.0.37 (Windows 7) and 7.0.42
(Linux). The web application is the same on all three servers.
Our web.xml file specifies:
web-app 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-app_2_5.xsd; version=2.5
So, I believe the correct behavior with 2.5 is that EL expressions
should be evaluated.
Note that the various EGs have made it clear that in many cases, your
descriptor's version number is irrelevant: the server will provide the
behavior of the most-recent version of the spec that the server
supports. (The Servlet EG and I differ on whether this is appropriate.)
Interesting and good to know.
I worked around the problem by adding the following to the JSP
files:
%@ page isELIgnored=false %
However, I'd like to understand where the configuration error is
occurring as from my perspective nothing changed except OS and
Tomcat version. My own efforts have turned up nothing helpful or
illuminating.
Where should I be looking in the configurations for a difference?
What differences would come into play?
What is your tag library declaration in your JSP file? That's probably
the most important thing, here.
Here is the top of the header.jsp file that is included by most (all?) of our
JSP pages:
!-- Header shared by a number of pages --
%@ page import=com.hcs.webtl.servlet.ScheduleBase %
%@ page import=com.hcs.webtl.util.CookieUtil %
%@ page import=com.hcs.webtl.util.WTLUtilities %
%@ page import=com.hcs.webtl.shiro.util.WebTimelineShiroUtilities %
%@ page import=com.hcs.webtl.filter.LegacyFilter %
%@ page import=com.hcs.data.dao.util.SiteAndFacility %
%@ page import=com.hcs.data.dao.util.DAOUtils %
%@ page import=com.hcs.data.dao.beans.Hostmap %
%@ page import=com.hcs.util.OAUtilities %
%@ page import=java.util.List %
%@ page isELIgnored=false % %-- This fixes misbehaving versions of Tomcat
that like to turn of EL (Expression Evaluation) --%
%--%@ taglib prefix=shiro uri=/WEB-INF/lib/shiro-web-1.2.2.jar %--%
%@ taglib prefix=shiro uri=http://shiro.apache.org/tags; %
%--%@ taglib prefix=shiro
uri=/WEB-INF/lib/shiro-web-1.2.2.jar/META-INF/shiro.tld %--%
%@ taglib prefix=sfp uri=/WEB-INF/SiteFacilityPermission.tld%
%@ taglib uri=http://java.sun.com/jsp/jstl/core; prefix=c %
%@ taglib uri=http://java.sun.com/jsp/jstl/functions; prefix=fn %
Obviously, I've already added the isELIgnored option to work around the problem
for the time being. A sample page that includes this starts with:
%@ taglib prefix=shiro uri=http://shiro.apache.org/tags; %
%@ taglib uri=http://java.sun.com/jsp/jstl/core; prefix=c %
%@ taglib uri=http://java.sun.com/jsp/jstl/functions; prefix=fn %
%@ page import=com.hcs.data.dao.beans.Hostmap %
%@ page import=com.hcs.data.dao.util.DAOUtils %
!DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
html
c:set var=j_username value=${param.j_username} /
shiro:user
meta http-equiv=refresh content=0;URL='/redirect' /
/shiro:user
shiro:guest
head
titleLogin/title
script src=lib/jquery-1.7.2.min.js/script !-- Need JQuery to
let us manipulate some text. --
link rel=stylesheet type=text/css href=style/header.css/
meta name=viewport id=iphone-viewport content=width=380
/
/head
body
%@ include file=header.jsp %
.
I'm assuming including taglib tags inside the body is fine, since that is JSP
vs. HTML.
Are you supplying your own version of
JSTL, EL, etc. along with your web application?
In the tomcat/lib directory, we've linked in (common to our Web Applications):
encorder-1.1.jar
jcl-over-slf4j-1.7.5.jar
jstl-1.2.jar
jul-to-slf4j-1.7.5.jar
log4j-over-slf4j-1.7.5.jar
logback-access-1.0.13.jar
logback-classic-1.0.13.jar
logback-core-1.0.13.jar
mail.jar
mysql-connector-java-5.1.21-bin.jar
Inside our Web App WEB-INF/lib we provide so of our own libraries and:
tomcat-jdbc.jar
tomcat-juli.jar
shiro-*-1.2.2.jar
org.json.jar
org.restlet.*.jar
commons-beanutils-1.8.3.jar
commons-collections-3.1.jar
I don't believe we've introduced any conflicts, but I could
isELIgnored default is wrong
Hello All, I'm seeing a strange problem where isELIgnored has the wrong default value for a new Tomcat install of 5.0.56. I'm moving a Web Application on Windows 7 to Windows 2008 and that caused the EL expressions to stop being evaluated on the new install.. Problem is only seen on Windows Server 2008 with Tomcat 7.0.56, while it works correctly on Tomcat 7.0.37 (Windows 7) and 7.0.42 (Linux). The web application is the same on all three servers. Our web.xml file specifies: web-app 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-app_2_5.xsd; version=2.5 So, I believe the correct behavior with 2.5 is that EL expressions should be evaluated. I worked around the problem by adding the following to the JSP files: %@ page isELIgnored=false % However, I'd like to understand where the configuration error is occurring as from my perspective nothing changed except OS and Tomcat version. My own efforts have turned up nothing helpful or illuminating. Where should I be looking in the configurations for a difference? What differences would come into play? BTW, other people apparently have run into this problem: See answer and comments on http://stackoverflow.com/questions/793983/jsp-el-expression-is-not-evaluated . Thanks in advance. Sincerely, Stephen McCants Stephen McCants Senior Software Engineer Healthcare Control Systems, Inc. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
