Mike Mitchell

Ranch Hand
+ Follow
since May 28, 2008
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Mike Mitchell

Howdy Ranchers! Finding my way back to this wonderful community after a few years away. About to undertake an OCMJEA campaign and glad to discover an active group of like-minded individuals. Looking fwd to getting to know you in coming months.

Cheers
Mike
echo Dan. Would love a Head First Web Services! But thanks nonetheless for this book. Did the SCJP 5 a couple years ago, and see this book as probably a pretty efficient way to prepare for the 6 upgrade exam. Are there particular differences between the 5 and 6 tests you might recommend I focus on?
You'll get a voucher for the exam when you take the course, which will expire roughly a year later.
14 years ago
You'll get a voucher for the exam when you take the course, which will expire roughly a year later.
14 years ago
Stunning result ... nicely done!!
14 years ago
And knocked out the SCWCD yesterday. Pretty much the same algorithm for pretty much the same result (85%). Thanks again to fellow ranchers, and especially Kathy, Bert and Bryan for the awesome book. You guys really have accomplished something special, making learning this stuff not just painless but fun. And I think I'm actually going to miss hot bitchy know it all servlet girl. Perhaps I've just shared too much. In any case, I'm looking to do Core Spring next ... could you guys maybe go ahead and whip up Head First Spring??
14 years ago
Thanks for the excellent exchange! I'm not yet to the filters chapter, but feel well-prepared after reading this.
Looking into this, I got an unexpected result for the RequestDispatcher include method. Please see screenshot and code below. Does it make sense the file included via RequestDispatcher seems to appear always at the top, and not where it was placed in the including page? Has this something to do with flushing out? I checked the entry for RequestDispatcher.include() in the 1.4 api and didn't notice a clue about that. Hope I haven't missed something obvious or done something careless.

Thanks,
Miike









In same chapter it is stated about cookies that:
"By default cookie lives only as long session. Once client quits the browser, cookie disappears."

Does that mean a session is destroyed when client quits the browser?



I believe not. See HFSJ CH6#3. The session exists serverside. The server has no way of knowing the client quit the browser ("there is no explicit termination signal in the HTTP protocol"). The session will live until the container times it out (or otherwise invalidates it). As Lukas notes, the session and cookie are different things.
Hi Lukas,

Is the issue that there will be an instance of the Counter class in each JVM, and so the actual count of sessions will be the sum of Counter.activeSessions variables in each JVM? If so, and short of keeping track of the session count externally (e.g. in a database), I wonder if this is even possible.

Is the A class meant to suggest a possible solution?

Thanks,
Mike
No that was instructional technology at it's best! I'd like to see one for scwcd as well.
Hi guys,

What is the motivation for RequestDispatcher.getNamedDispatcher()? I see in the API it 'Returns a RequestDispatcher object that acts as a wrapper for the named servlet.' I'm having trouble imagining what the value of having a wrapper for a named servlet is. (And furthermore how it might bear on HFSJ CH5#12, given below.)

Thanks,
Mike

Which statements about RequestDispatcher are true (where applicable, assume the RequestDispatcher was not obtained via a call to getNamedDispatcher())?
(*) A. A RequestDispatcher can be used to forward a request to another servlet.
B. The only method in the RequestDispatcher interface if forward().
C. Parameters specified in the query string use to create a RequestDispatcher are not forwarded by the forward() method.
D. The servlet to which a request is forwarded may access the original query string by calling getQueryString() on the HttpServletRequest.
(*) E. The servlet to which a request is forwarded may acces the original query string by calling getAttribute("java.servlet.forward.query_string") on the ServletRequest.
Howdy Ranchers,

I have a question about listener notification order I'm hoping you can help me with. The answer to the following question (HFSJ CH5#11) is given as C, as listener order is determined by the order in which they're declared in the deployment descriptor, and B we're told is wrong because 'the container uses the DD to determine the notification order of registered listeners.' But what about binding listeners, which (per p183) are not registered in the DD? For example, if I have an object that implements HttpSessionBindingListener, and I bind it to a session, is it predictable whether the object bound will be notified before or after an HttpSessionAttribute listener? I did a test (on Tomcat 5.5) and found that the object's valueBound() fired before my HttpSessionAttributeListener, but I wonder if that's guaranteed to be the case from container to container (or from certification test to certification test :-)).

Which are true? (Choose all that apply.)
A. When a web application is preparing to shutdown, the order of listener notification is not guaranteed.
B. When listener-friendly events occur, listener invocation order is not predictable.
C. The container registers listeners based on declarations in the deployment descriptor.
D. Only the container can invalidate a session.

Thanks,
Mike


After the read I'd have 389 meaningful bytes in my 1024 array. With the first form of write, I was writing all 1024 (because bytes.length is 1024 of course), and with the second, I was writing only the number of bytes read into the buffer.

Thanks Paul!
15 years ago