Erick Jones

Ranch Hand
+ Follow
since Jun 17, 2002
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Erick Jones

Thomas,
The results of my test confirmed our interpretation. Two cookies with the same name, but different paths, are both stored by the client and do not collide with each other. The correct cookie is then sent back to the server based on the URI path of the request.
This is the solution to my problem. Thanks again for your help!
Erick
21 years ago
one more time...
<HTML>
<BODY>
<a href="javascript:document.forms['myForm'].submit();">test link</a>
<FORM ACTION="/webapps/servlet/servletName" METHOD="POST" NAME="myForm">
</FORM>
</BODY>
</HTML>
21 years ago
Ok, third time is a charm...had a typo in my last post
21 years ago
Here it is again, and I have disabled the smilies...
21 years ago
21 years ago
Thomas,
Thanks for the reply.
The web applications that I am calling the 'Task Resolution applications' exist in our production environment today. So the impact of changing over to use URL re-writing would be very large. I hadn't thought of this being a solution to the problem, but I think it would work.
The second point you made will work for me if I understand correctly. After reading RFC 2109, let me see if I understand correctly how the path of a cookie works:
If two cookies have the same name and the same path, only one cookie will exist on the client. If two cookies have the same name, but different paths, two cookies will exist on the client. The cookie sent to the server is then based on the URI of the request. If this summary is correct, then I am a very happy man!
Thanks again for your help!
Erick
21 years ago
Assuming that you have an html form in your page, with a METHOD of POST, you can use javascript to submit it when you link is clicked.
<a href="document.form['formname'].submit();">my link</a>
Erick
21 years ago
Bill, let me try to clarify...
The Task Manager application runs in one Application Server. Each appplication that is launched from it will be a web application in another Application Server (another JVM).
The issue is not that I need to share information between the two applications. This is not a requirement, and I know that this is not supported within the J2EE spec. The issue is that when the user launches a task resolution screen (which is in another app server) in another window, a new session will be created and a new JSESSIONID cookie will be sent back to the client. If the user now goes back to the Task Manager window, and initiates a request (via a POST), the cookie will have the sessionid of the HttpSession in the other JVM. Therefore, the web app will not be able to locate the session and it will be lost.
Hope this helps better explain my situation. Any help is GREATLY appreciated.
Erick
21 years ago
Background info...
I am creating a web application that manages tasks for a user. Each task provides a link for the user to resolve the task. Each link will potentially take the user to another web application in another application server. The resolution applications will be opened in another browser window. This is so that the user can view their tasks, monitoring for new ones, at the same time that they are resolving a particular task. Both the task manager and the resolution applications will be using the HttpSession. Each will have its own HttpSession since they will each be in their own JVM.
Question...
Since I will have one browser instance with multiple windows, there will be only one JSESSIONID cookie on the client. I am in the design phase so I have not actually tried this, but I am assuming that it will not work to switch between windows because the cookie that is passed to the server will be for the JVM of the previous response. The end result is that I will lose the sessions. The only solution that I can think of would be to create a unique sessionId cookie name for each app server so that name collision does not occur. However, I understand that the Servlet Spec says that the cookie MUST be named JSESSIONID.
Am I correct in my assessment that there is a problem? And if so, does anyone know of a solution? Also, why does the Servlet Spec require the cookie to be name JSESSIONID?
Thanks in advance!
Erick
21 years ago
Sounds like there may be a bug in the oreilly package. One workaround would be to give the options a value. This will then be the value in the request when the form is submitted.
For example,
<SELECT NAME="category">
<OPTION SELECTED VALUE="cc">Child Care</OPTION>
</SELECT>
You will just have to change your code to check for "cc" instead of "Child Care".
Hope this helps!
Erick
21 years ago
You can use the java.net.URL object to open an InputStream.
URL url = new URL("http://www.ibm.com");
InputStream stream = url.openConnection();
Erick
21 years ago
JSP
Thanks for the reply Chris!
I am using the <jsp:include> tag. I guess I didn't realize (until now) what the meaning of translation unit was, and why the spec would not allow multiple @page attributes. Since the generated code for an included file (i.e <jsp:include> is actually another servlet there is no problem with having a duplicate @page attribute. If I change to an <%@include> tag then only one servlet is generated, and I get an error like I would expect:
"Page directive: can't have multiple occurrences of contentType"
So the end result is that I can safely set the contentType attribute in both JSPs since they are in separate translation units.
Thanks again,
Erick
21 years ago
JSP
I am trying to display unicode characters within a JSP.
It works fine if I set the contentType in the @page directive to "text/html;charset=utf-8". However, if I include another JSP from within the first, the unicode characters from the second JSP show up as garbage.
I can get around this by also setting the contentType within the 2nd JSP to utf-8. However, the JSP specification says that only one @page attribute can be specified per JSP translation unit. So what I am doing is a violation, and I am surprised that it even works.
I am using Visual Age for Java 3.5.3, which uses JSP 1.1. Any thoughts on what the problem may be?
Erick
21 years ago
JSP
Are you accessing your JSP directly, or forwarding to it from a servlet?
Try placing it in your JSP.
21 years ago
JSP
The browser picks up the encoding of the response object. Therefore, you need to set the encoding on the response before it is sent to the client.
For example,
response.setContentType("text/html;charset=TIS620");
21 years ago
JSP