Marty Hall

First a big JavaRanch thank you to Marty for being here this week! We hope you had a good time and you'll come back and visit us!

Thanks for having me! I enjoyed it.
Cheers-
- Marty

He stated it clearly that this applies to medium/large web application projects. There is no gainsaying the fact that for small projects Microdoft products have an upper hand for obvious reasons.

Perhaps. But another way of looking at it is that almost any technology is fine for the small apps: J2EE, ASP.NET, ColdFusion, PHP, CGI with Perl, etc.

However I want to thank Marty for his candid opinion on this issue, though I strongly believe that Microsoft .Net will come around to blow the leading rug out of the feet of java; its just a matter of time.

I am not as pessimistic as you are. .NET has been around for a while no, and although it has a fair sized market, it is hardly taking over from Java. My guess is that JSP/servlets/J2EE will continue to hold a slightly-larger market share for the foreseeable future. (Of course, "foreseeable" is not very long in the software/internet world ).
Cheers-
- Marty

Because I have been asking him a lot questions about the advance topics and he always replies that they are in the volume II... So I can also guess that such kind of concurrency and multi-threading stuffs will be in the volume II.

Well, I most definitely cover concurrency and multithreading issues in the first volume; you cannot avoid dealing with these issues even in less complex applications.
As to handling multiple form submissions, I am not sure I understand the question.

Is it asking what if two submissions occur (from different browser windows) from the same user simultaneously? If so, I address this specifically in the session tracking chapter (synchronize, but use the session object, not "this" as the argument to "synchronized").

Is it asking how to differentiate between two requests by the same user to purchase the same item (ie you want two entries in the shopping cart) from two accidental submissions of a form that purchases an item (ie you want to ignore the second submission)? If so, I admit I haven't thought a lot about how to tell these two cases apart.

Cheers-
- Marty

Thank you, Marty... I saw you posted this thread in the morning 5:47...

Actually, my time zone is two hours later than the time zone of the system that hosts javaranch. So, it was actually 7:47 AM my time.

I can figure out now that most of the advance topics are in the Volume II. I think all the fundamentals and essentials to build a good web application are in Volume I...

Yup! That's the goal, anyhow.
Cheers-
- Marty

Come on, Marty. One question from me is left out... Are u still here??? I think Marty has already fallen asleep at this time...

Actually, I had already gone to bed when you posted that last question.
Yes, Volume II covers the event listeners including the new ones. More Servlets and JSP (see http://www.moreservlets.com/) already covers all the existing ones.
Cheers-
- Marty

Is JSESSIONID a cookie ??
How does the container & application manage it ??

If the server is using cookies for session tracking, then the name of the cookie used will be JSESSIONID. So, for example, calling request.getSession will result in the server checking to see if there is already an incoming cookie called JSESSIONID and setting an outgoing cookie of that name if not.
Normally, you never deal directly with the cookie; it is a behind-the-scenes tool used by server. However, that cookie has no max age, which means it will be stored in the browser's memory and lost when the user quits the browser. This is normally the behavior you want, but sometimes people want to use the session tracking API but have it based on persistent cookies. In such a situation, you can grab the incoming JSESSIONID cookie, set its max age with setMaxAge, and send it back out again with response.addCookie.
Cheers-
- Marty

Do u mean JSF is not widely used in the industry yet?

Actually, I meant that JSF is not used at all in industry yet.
The spec is not complete, and the first release of JSF is not yet out.
Cheers-
- Marty

Since both the applications are running in the same container I was just wondering what security issues could come up?

Just because two Web applications run on the same sever (same container) does not mean that they are developed by the same people and want to share data arbitrarily. For example, I teach a JSP/servlet class in the Johns Hopkins University part-time graduate program in Computer Science. We use Tomcat, and each student has their own Web app (mapped to http://hostname/~userID/, in fact). One student shouldn't be able to change/delete entries in another student's ServletContext, so we have this disabled.
Whether myServletContext.getContext(contextPath) returns null or not depends on the container settings -- in Tomcat you get null unless server.xml specifies crossContext="true" for the app or for DefaultContext.
Cheers-
- Marty

Well, the advantages I see in JSF is not just in rendering plain HTML form elements the first time, it is:

Associating the form elements with beans so that the values of the form elements (textfield contents, button labels, etc.) can be derived automatically from the bean.

Associating the action with a bean so that the results of the form submission can populate a bean automatically.

Easily redisplaying HTML forms when they are incompletely filled in, preserving the entries that have already been filled in.

As to whether the JSF project is going well or not, IMHO it is too early to tell.
Cheers-
- Marty

I guess what I am trying to ask if I can control the number of sessions an user can initiate in one web application.

I am still not sure I understand the question. If the user comes back to the container within the session timeout and without quitting his browser, they will not get any more sessions -- they will get the same one. If one user is getting multiple sessions, then you have to ask why.

Because they have cookies disabled? Then I suspect you cannot detect that they are the same user, so you cannot limit the number of sessions.

Because the session timed out? You can change the session timeout with setMaxInactiveInterval (or in some more general way using server-specific settings).

Because the user quit the browser? Normally, you want that to end the session, but you could read the incoming JSESSIONID cookie and send it out with a max age so that sessions persist even when the browser is quit.

Or did you really mean you wanted to limit the amount of data that would be stored for a user within their single session object?
Cheers-
- Marty

Don't you think that with the introduction of JSTL, and the power of its iteration tags, there will be very rare cases where someone need to write his own looping tag?

I didn't mean "general iteration tags," I meant "tags that do some sort of looping (ie evaluate their body content more than once)." Yes, I think people will still write tags that do this.
Cheers-
- Marty

You also might want to take a look at http://resources.corejsp.com/scwcd.html.
Cheers-
- Marty

>can any body tell me from the beginning what i need to do to run a servlet program
>how to set the path & all

Please see http://www.coreservlets.com/Apache-Tomcat-Tutorial/.
This walks you through setting up Java, Tomcat and your development environment. It also gives you some simple JSP pages and servlets to test to see if you have things working properly.
Cheers-
- Marty

If I am using a cookie to manage session state, If I launch another IE from start menu what determines if that IE browser window will be using the session with cookie or it will be a new session?

Good question. Let's assume that you are using the default way of session tracking (which is where the server sends the JSESSIONID without a max age, so the cookie is kept in the browser's memory, not stored on disk).

If the user opens a new IE window from the Start Menu or desktop icon, that new IE window will not share the in-memory cookies with the old window, so thus will be in a new session from the Java perspective.

If the user opens a new IE window from the old window's File menu or by hitting Control-N, that new IE window will share the in-memory cookies and will be part of the same Java session.

Also, don't forget that the spec advertises the name of the cookie that will be used (JSESSIONID). So, you can resend that cookie with a max age, and then use the normal session tracking API after that.
Cheers-
- Marty

I am not sure I understand the exact question, but you realize that persistent cookies (cookies where you setMaxAge) are shared across multiple IE windows?
Cheers-
- marty