P. Dunn

Does anyone know when the SCJP for 5.0 (non-beta) will be available?
AKA:

311-055 ? (Is this just the Beta #?)

SCJP Tiger

Sun Certified Programmer for the Java 2 Platform, Standard Edition 5.0

Sun Certified Programmer for the Java 2 Platform, Standard Edition 1.5

How about plans for a 1.5 study guide?

Bert/Kathy- There's your segue-way. I welcome any plugs for future books
[ March 08, 2005: Message edited by: P. Dunn ]

I believe this is a straight XML/DTD question. The parser would(should)complain when loading this out of order.

The description element gave me problems. It's all over the place. The best rule I could come up with is it comes after icon, name, or id, if they exist. So for servlets and filters, it's not first. Everywhere else, it's first.

Attributes have no order in XML.

I know nothing about schemas (servlet 2.4). I don't know if they have different rules.

Originally posted by Lucy Hummel:
I passed today with 85% score.
BTW: I did not even write a JSP, Servlet, taglib.

Purely theory eh?

You need to pass SCJP first.

Originally posted by Jose Esteban:

This DOESN'T mean that the attributes will not conserve their values; it ONLY MEANS that the readObject and writeObject methods on these attributes could not be called.

Yes, after a night's sleep and looking back at HFS, I agree. The the implication is the container transfers the attribute state in a way of its choosing.

Originally posted by Marco Tedone:

Yes, confirmed. The HttpSessionActivationListener and HttpSessionBindingListener don't need to be declared in the DD. I know it because my colleague took the exam last week.

I can't find anything to corroborate that a HttpSessionActivationListener need not be in DD. HFS saqys the opposite. Could your colleague have gotten it wrong?
Could you give a reference? Anyone?

BTW : Thanks Marco. Nice summary.
[ March 03, 2005: Message edited by: P. Dunn ]

Originally posted by Romy Huang:
what order it is in listener register?
Is it dependend on listener declaration in DD?

I think so. Listeners usually do, but I can't find a reference.

Thanks! good catch.

I should have stipulated. I haven't taken the SCWCD exam yet. Though I've taken others. The others didn't have darg-n-drop. So I don't know.

HFS corroborates what I said about # of answers given on p759.

Originally posted by Bert Bates:
Hey Mike -
I think there are a very few places where Bryan and Kathy and I had a disconnect between what was on the exam, what was in the chapters, and what made it to the coffee crams. I'm checking with Bryan and Kathy to see if they might have a list of those disconnects.
HTH, Bert

Here's some disconnects that burned me:
Q6 p561 compare to statement bottom of p.544 findAncestorWithClass
Q7 p672 Dynamic attributes not covered in text
Q7 p613 relevance of http://java.sun.com/JSP/Page not covered
Q12 p615 xmlns attribute xmlns="http://java.sun.com/JSP/Page" not covered
Q9 p613 <resource-ref> DD element not covered in text

I have not yet done mock exam.

There should be separate <security-role> element for each role.

Following the specs, it seems that Durgaprasad is right...

Yes. In the spec, I looked looked up
<!ELEMENT auth-constraint (description?, role-name*)>
not
<!ELEMENT security-role (description?, role-name)>
[ March 03, 2005: Message edited by: P. Dunn ]

No, it tells you how many to choose.

If the cookie were gone, there would be no way to reassociate the user with the session. So it would never used again. An HttpSession that could never be reassociated with a user would be garbage, and for all practical purposes, invalidated. (Though it would still exist as an object.)

The cookie is not eliminated when the browser closes. It's reused until the cookie expiration date passes.

Though VERY ambiguous in the Servlet spec, I believe the session-timeout element is different from what you call "sessionLive." I believe the container periodically looks for expired HttpSessions. I would define InactivePeriod as measured from the LastAccessedTime to now, irrespective of creation time. The primary concern is reclaiming inactive session objects. I understand your interpretation, though.

Someone needs to rewrite the DTD where it defines:
"The session-timeout element defines the ... session timeout..." Doh!

PS To Add one other odd detail:
According to the DTD:
* If the timeout is 0 or less, session will not expire.
According to the API:
* setMaxInactiveInterval(int interval)if interval<0, session will not expire.(if interval==0, session expires immediately. Wow! Somebody fix that!)
For cookies:
* A negative value means that the cookie is not stored persistently and will be deleted when the Web browser exits. A zero value causes the cookie to be deleted. (Though different it makes sense, because cookies must have some timestamp.)

Originally posted by Colin Fletcher:
> ...attribute values that implement java.io.Serializable will be transferred to the new JVM.
>[container] does not guarantee the object will retain its values in the new JVM.
>Spec:
Developers are not guaranteed that containers will call readObject and writeObject methods on session attributes if they implement them, but are guaranteed that the Serializable closure of their attributes will be preserved.

Although I'm disturbed by this news, apparently the difference (based on the semantics of your quotes) is that the object is transferred, but none of its internal property values are guaranteed to be transferred. I'll attempt to reuse the words of the question: the "attribute value" (attribute object) is transferred, but any property of that "attribute value" is not guaranteed to retain it's (the property's) value.

If I am correct, the attribute class should implement HttpSessionBindingListener to solve this.

BTW Who came up with the phrase "Serializable closure"? That's awful.
[ March 02, 2005: Message edited by: P. Dunn ]

Yes, I see your point about normal curcumstances. Normally you'd shutdown the container at least a few times a year, I'd assume, making most of this issue theoretical.

However, this is the thing that is odd to me. If cookies must have an expiration date, a session timeout of -1 just means the session will last only as long as the cookie's expiration, which is determined arbitrarily by the container. So, effectivly, there's no "ever-lasting" session

BTW, in your code, correct me if I'm wrong, but I believe you meant ... if ((System.currentTimeMillis() - HttpSession.getLastAccessedTime() )> sessionTimeout) { HttpSession.invalidate(); }
[ March 02, 2005: Message edited by: P. Dunn ]