Lou Umile

Makes sense. Thankfully, nothing in either context uses the same class, as these are all internal business models developed mainly for SQL interaction, so there's no spots where the same class can be duplicated. The session Id will just be used to authenticate that the user is passing over the correct credentials.
Thank you for going through the explanations you've posted. This helped me immensely.

Tim,
I'm glad you pointed that out about the session possibly changing mid-session, but that would be fine. All the user would experience in that case would be one of the links asking him/her to log back in. I'd like your advice on something, however.

After your explanation, I set up a test server which mirrors our current codebase. using this guide, I've got the session ID coming up the same from the two contexts we use. More importantly, logging onto the site from any other computer gives a different session ID, which is accessed by both contexts. I tried having two people interact with the site simultaneously, and didn't notice any issues with both computers getting each other's data. It looks like I've now got the two contexts sharing the Session ID, which is IP specific. If you have experience with setting this up, could you tell me if there's anything you notice which I've overlooked in terms of securely using this technique?

Right, the part about apps1-3 not seeing each other I was aware of. I had checked all the conf files in TOMCAT_HOME/conf/server.xml because I have found config settings in the past which were "good enough" for a temporary workaround on this project's nascent stages, but were never fixed or updated. The last programmer and I had different styles of programming, to the point where he'd only read documentation until he found something that worked for him, then forget to see if there's a better way of doing something. So, I occasionally get bit in the kiester by something he did a while back, because there was a "lone gunslinger" mentality with the development teams in all the call centers that left me no end of grief. I know we haven't started tinkering with explicit contexts for defining alternate URLS since that guy left, and so far nothing has been defined in the universal config files, but I wanted to check those to be thorough.
When I say <WEBROOT>, I'm referring to <TOMCAT_HOME>/webapps/ROOT, which is where our main app is deployed. I guess the better way I could have described this is that we took the app from a different department, and only put enough of it in to be a resource of the first app. As it stands, we have 30-40 resources of our root app, all accessed via ajax, with our root app functioning as the web portal and handling log-ins, sessions, and employee identification.
I guess the best way to phrase my question would be: Under normal circumstances, should all resources in the same context get the same session ID number from httpSession?
Also, does the first volume of [i]Core Servlets and Java Server Pages [/i] by Marty Hall cover all this in detail? I'm going to try and get through it during the winter session, using a clean install on my home Ubuntu box so I can get used to working with Servlets and configuring Tomcat.

Tim,
I really would like to thank you for taking the time to clarifying this, and I hope I'm not just being dense in trying to clarify my question. I understood part of what you mentioned when I had previously checked my server, but some of what you explained did clear a few other things up. I've looked through the deployment descriptor and all other xml files for a definition of sulaco anywhere, and only found it defined as a resource in <WEBROOT>conf/server.xml for the purpose of linking it to the sql driver and setting timeout. Would that be enough to qualify as defining a context?
Am I correct in assuming that if I define <WEBROOT>/index.jsp as a context, and make no definitions whatsoever of <WEBROOT>/subdir as a separate context, then <WEBROOT>/subdir/index.jsp should be able to access the same session ID using httpSession? This is how I have the pages set up, since I had to take part of a full online application and add it's functionality into our app. However, as I understand your explanation, the fact of having a folder with an index.jsp file as a sub-dir will even be picked up as a separate context for the purpose of creating a default context. So, if I take my main app's (Nostromo) exploded WAR and code an index.jsp file in a new subfolder (Betty), shouldn't the session object called in a link from http://Nostromo/index.jsp to http://Nostromo/Betty/index.jsp get the same session ID?
I apologize if I'm not getting something here.

Perhaps I phrased this wrong. I'm referring to a context to denote two different processes on one server. Neither application is set up as a WAR file. The entirely of the suite is, in fact, exploded into a common file hierarchy. I know this is not the way Tomcat is expected to be used. The problem lies in the fact that I have one very large web suite which was designed by a former employee who sort of knew how to work with JSP and Tomcat. At the point after he left, I inherited his entire code base. We were then given another application/nested directory, which ran independently on one server in a different call center for the same company. This got installed as a sub-folder of our web root,. If we were to call the original suite Nostromo, we access <WEBROOT>/index.jsp by going to http://nostromo. Another call center in this company developed the application Sulaco, which is on their Tomcat install and accessed at http://sulaco. However, I was told we needed to have Sulaco work in my center, so what would be the root got installed at <WEBROOT>/sulaco. Now, we can access it through http://nostromo/sulaco, but get different session IDs. To my way of thinking (and if I'm misunderstanding, please correct me), the Tomcat server should see someone logged in to http://nostromo, then said person clicking on a link from the main page for http://nostromo/sulaco would qualify as accessing a page within the same context. Is this wrong? I understood it to be similar to me creating a sub-directory called <WEBROOT>/rotovator, with page rotovator/index.jsp, at which point I would expect that rotovator/index.jsp would pull the same session ID from the browser as nostromo/index.jsp would, since they're in the same context path. In fact, that's exactly how I have this set up, and both suites work together in all other aspects which I've had a chance to test, except session ID.
Is it possible I've just not found some definition (analogous to a symbolic link) in a conf file somewhere that tells Tomcat to treat /nostromo/sulaco as a separate context?

I am trying to figure out why I get two different session ids when I call two pages from the same web root. I thought I had declared the scope of each page properly, but the two pages will not "talk" to each other. I would appreciate anyone who can point me in the right direction for understanding what I'm doing wrong.
I'm working on code stored on a Tomcat 6 server with Java 6 on an Ubuntu server. Almost all the pages are written in JSP (including the two I'm working on). The web root's index.jsp has code to check if a session variable "netID" is set. If not, it prints out a splash/log in page. If "netID" is a field in the HttpSession object, the user gets the main page, which is also part of the code in <WEBAPPS>/index.jsp. This output is controlled by very large "if...else" statement.
I have this page printing the username from this session and the ID to Catalina.out for testing purposes. The page is set to session scope using a <%@page session="true" %> declaration, and also has a JavaBean which I believe is instantiating properly, as I can pass values in to it and call them out or call them without passing them in first.
There is another package, which has it's own login screen as this was absorbed from another department into our web schema. What was the web root of the second package was placed as a folder directly under the first package's web root, so that our schema is now:

<WEBROOT dir>
|
+-----index.jsp
|
<project2 dir>
|
+--index.jsp

This feeds from a MySQL database backend through JSP for the passwords and user data. Both contexts will pull from the database without issue, as this has been running for a little over two years now. I simply cannot get the session to be recognized in both locations. Instead, opening either page creates a session unique to that page, but:

Going to <WEBROOT>/index.jsp will give me a certain session ID (let's say ABC123), whereas going to <WEBROOT>/project2/index.jsp will give me a different session ID (XYZ789). If I refresh either page, I get the same ID. If I go back and forth, each page keeps it's own ID. If I:

1) go into <WEBROOT>/project2/index.jsp after restarting my server
2) load <WEBROOT>/index.jsp
3) open <WEBROOT>project2/index.jsp in a separate tab of the same window

I get project2's Session ID from step 1 showing up in step 3, which is what I would expect and proves that the server is finding Session IDs fine. I've checked my server's config files and found no instance of anything specifying separate Session IDs (although I only know enough from googling and checking other posts in here to make an attempt at verifying this, and claim no expertise).

My session declarations are as follows:
<WEBROOT>/index.jsp:
<%@page session="true" import="java.util.*" %> <%@page pageEncoding="UTF-8" session="true" %>

<WEBROOT>/project2/index.jsp
<%@page session="true" import="java.util.*" %>

With bean declarations (currently removed) the code was:
<WEBROOT>/index.jsp:
<%@page session="true" import="java.util.*" %> <%@page pageEncoding="UTF-8" session="true" %> <jsp:useBean id="sessionUser" class="admin103.userBean" scope="session"> <jsp:setProperty name="sessionUser" property="*" /> </jsp:useBean>

<WEBROOT>/project2/index.jsp:
<%@page session="true" import="java.util.*" %> <jsp:useBean id="sessionUser" class="admin103.userBean" scope="session"> <jsp:setProperty name="sessionUser" /> </jsp:useBean>

<WEBROOT>/index.jsp called the setUser() method of admin103.userBean explicitly in the jsp code, passing it an object of type supportUser (an internal naming convention). I had originally planned to create a class userProfile and assign it to the session as an object, but that failed too due to the session IDs being different. I'm convinced I'm just not understanding some detail about how Session IDs are assigned. Could anyone point me in the right direction to figure out what I'm missing?

I've noticed this issue appear in multiple posts in this sub-forum. I apologize if this is the wrong spot to bring this up, but I think it might be helpful.
I've been reading up on servlet programming in Core Servlets and JavaServer Pages, Vol. 1 by Marty Hall. One of the conventions which this book uses is that the first line of the Document Descriptor is
<?xml version="1.0" encoding="ISO-8859-1" ?>

The author explains that the encoding allows it to work with both serlets 2.3 (JSP 1.2) and servlets 2.4 (JSP 2.0). However, this appears in a number of threads where someone has said that it was causing their servlet to not be recognized. Apparently, in some cases, substituting UTF-8 for ISO-8859-1 has resolved the issue. Since this is a popular book, perhaps this would be a good addition to the FAQ under things to check if your servlet is not working?
Has anyone had this issue with Headfirst Servlets?

Looks like either a corn snake, or a rat snake. Of course, I only really know American snakes, and I've not looked at your location, so it could be something completely different. how big is it? From the background, it looks like it's about an inch thick, since I think that's some sort of slate/concrete tiles in the background.

Ben: I think your second suggestion is the best way for me to set this up. Thanks to both you and Bear for the clarification.

Bear: I've been going through the Tomcat Manager docs, and I notice that my test environment (which is running 6.0.18) is completely missing. Is it possible to delete that entire part of Tomcat without messing up the whole server?

Bear,
OK, I see what you mean. In the future, I'm going to start using that layout whenever possible. For this instance, I would do that, but the only problem is that I have to put this in as a sub-directory of the ROOT dir, since this is an app that gets accessed through a web portal with security features. One of the big reasons is that our permissions schema populates a menu of apps which a user can access. While I realize that putting it in as a separate folder under the root dir would not keep the project from being accessed, our layout and backup schema are such that this would be difficult. The app which is housed in ROOT functions as the portal in which we invoke all of the different functionality in our "apps" folder, which is the individual app/web-tool repository.
As one of my teachers would say, "That's a reason, not an excuse." Why I have yet to fix this design is that we're pressed for time on our projects at my job, so the time it would take to redesign this whole system is having to be spread out over "whenever we can," which is a slow process.
I'm going to look into the App Manager and start working with that for my own projects outside of work. Is there a FAQ you could suggest which would expand upon the idea I can also map a context separately so that you can place it anywhere?

Hello,
I'm getting a 404 error when trying to access a servlet. After trying several solutions I found listed in past forum posts (and cleaning up the way I mapped the servlet), I'm still not able to get it to show up. I'm using Tomcat 6.0.18 on Ubuntu, and have deployed the app into the following directory structure:

{Catalina-webroot} | ROOT | apps | hr | previsor | WEB-INF | +-web.xml | +-classes | servlets | entryServlet.class

I verified that the entryServlet.class file exists, and have set up my web.xml file as such:
<servlet> <servlet-name>entry</servlet-name> <description>Maps /servlet/entry to servlets.entryServlet().</description> <servlet-class>servlets.entryServlet</servlet-class> <init-param> <!--nothing initialized --> </init-param> <load-on-startup>5</load-on-startup> </servlet> <servlet-mapping> <servlet-name>entry</servlet-name> <url-pattern>/entry</url-pattern> </servlet-mapping>

I've tried http://localhost:8080/entry, http://localhost:8080/apps/hr/previsor/entry, and http://localhost:8080/hr/previsor/entry. Our makefiles delete the class files and remake them each time I run our distro script, at which point I check for compile errors and get none. Also, I see a fresh class file each time.
I grepped all the Tomcat logs. I find no error messages in any of them, except localhost_access_log, which shows requests for each URL I type, and a 404 error. For example, typing "http://localhost:8180/entry" results in "GET /entry HTTP/1.1" 404 970, which I would expect means it's reading the servlet mapping as absolute from the ROOT directory in Tomcat. I was under the impression that if I define a servlet mapping in a web.xml file inside the WEB-INF folder of a context, it would treat the top level of the context as the root for the purpose of reading definitions inside web.xml. If this is the case, then by my way of reasoning, the GET request should show "/entry" where / denotes the web root. I also tried changing the encoding type, to no avail. Is there something else I can try, or a glaring error I'm not catching?

Ah, thank you. I didn't want to clutter things up.

processReferee.jsp *SHOULD* read:

# <jsp:useBean id="newEntry" class="referral.NewReferee" scope="request"> # <jsp:setProperty name="newEntry" property="*" /> # </jsp:useBean> # <%System.out.println("name: " + newEntry.getName());%>

Kris: That's actually something that was concerning me, so I checked, and sure enough, it occurs even without an instance of NewReferee initialized. Of course, I only caught this because one of the pages I was reading on this subject mentioned that if there's an instance existing, it will ignore the body. I was starting to think that the information about whether it would initialize with another instance existing was an example of how web resources sometimes give bad information. Thank you for the heads up, and confirming what I read.

Bear: I know it seems odd, but people here have gotten in trouble for what I thought were innocuous things, so I'm extra careful. As for needing the actual code to offer suggestions of what to try, this is the actual code. I simply used string substitution to change variable and package names, because I knew that asking any more vague of a question wouldn't help. I'll edit that code example to fix my typo, as well.

Edited to add: I seem to have exceeded the time constraint for editing the entry. Is there another way I can correct it?

Jonas: exactly. It gives me "name: null" in Catalina.out.

Bear: the reason I didn't just do this as a servlet is that I need to learn to write servlets. I've basically been given an orphaned project from someone who left the company. While I'm ok with java in general, I'm trying to get time to teach myself servlet programming. As for the article, it gave me a strong idea of where to proceed with the basic design of this project. Before, everything was passed around with appending arguments to the end of URLs and using GET. I'm in the process of changing that. As for the field "name," it's actually "lName" and "fName," which I truncated for the purpose of brevity in my example.

David: My typo. Since I don't want to have to worry about my employer getting upset over me posting this, I sanitized the names. It should read "newEntry.getName()."

I'm having a problem with a Bean I created for accepting entries via "post" in a form on a JSP page. All I get are null values, and I can't find where I'm going wrong.
After reading Bear's article entitled "Scriptless JSP Pages: The Front Man" from the May 2006 journal, I started working to move the logic for handling the form data off the primary page (something which was done often in the code here, and from where i picked up the bad habit myself). So, I have the following code on the page containing the form:
<----snip out the html page set-up----> <form method="post" name="newReferee" action="processReferee.jsp"> <----snip out the standard form input fields ---->

The receiving page (processReferee.jsp) has the following code:
<jsp:useBean id="newEntry" class="referral.NewReferee" scope="request"> <jsp:setProperty name="newEntry" property="*" /> </jsp:useBean> <%System.out.println("name: " + newReferee.getName());%>

The bean itself is named NewReferee, and has the format:

package referral; public class NewReferee { String name; public NewReferee() {} public String getName() { return name; } public void setName(String value) { name=value; } }

I realize that passing the POST to a JSP is poor form (as is the system.out.println), but this is just to test that I'm getting values passed over. I'm going to fix that after I get this issue resolved. The page processReferee.jsp will be changed to a servlet which calls another part of the "referral" class (one I've yet to write), passing it a linkedHashMap of name/value pairs, and then redirect to the original data entry page, ready to accept more entries.
I also set the scope to "session," with no change. Can anyone point me in the direction of what I'm missing?