Peter den Haan

author
Ranch Hand
+ Follow
since Apr 20, 2000
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
4
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 Peter den Haan

Seconded, erm, thirded. This is a great book. (Disclosure: I was one of the reviewers, so I may be biased, but TN really is one of the few who could pull this book off).

- Peter
13 years ago
Beginning JSP 2 has had an eventful start in life. It was written when both Tomcat 5 and JSP 2 were still in development, edited and published by Wrox in great hurry just before they went bankrupt. If you find the Wrox version of this book somewhere, to be honest, stay away from it unless you need a sturdy monitor stand. Buy the Apress reissue (as reviewed above) instead. Matthew Moodie has done a brilliant job re-editing the book.

Thanks for the review, Dirk; and HZ, apologies for the occasional remaining rough edge. Fortunately the servlet-api.jar one is not hard to figure out.

- Peter
13 years ago
The "stateless" nomer applies to conversational state only, i.e. request or session state. There may still be configuration information. I think the idea is that you configure your servlet using a tool and then serialize it out complete with its configuration information. Once more this is to some extent analogous to SLSBs which may maintain cached results from JNDI lookups and the like.

- Peter
13 years ago
Why on earth is everyone still using <logic:iterate> and the rest of the Struts logic taglib? The JSTL is much superior, and the Struts boys know it:

Note: - Many of the features in this taglib are also available in the JavaServer Pages Standard Tag Library (JSTL). The Struts team encourages the use of the standard tags over the Struts specific tags when possible.

The only situation in which I would consider using the Struts logic taglib is on a JSP 1.1 container, and they too are stone age technology by now.

Mystified,

- Peter
13 years ago

Originally posted by John Smith:
I have the same except my taglib are contained by <jsp-config></jsp-config> tags, I'm not sure if they're necessary or not but it works fine for me.

This is because you have a Servlet 2.4 / JSP 2.0 deployment descriptor, while VK probably has a Servlet 2.3 / JSP 1.2 deployment descriptor.

- Peter
13 years ago

Originally posted by Venkatesh Kumar:
I still keep getting the exception which says invalid TLD resource path.can anyone tell me where I am going wrong .

Take the error message seriously. Your TLDs aren't where you say they are. The paths you give are in a directory called src; are the tlds in the deployed web application?

By the way, there was no need to change your taglib URIs. They are just identifiers and have nothing to do with the physical location of the TLDs. They can be anything. BUT. The Struts taglibs have a default URI, such as http://jakarta.apache.org/struts/tags-bean for the bean taglib; just look near the top of the TLD file. I would strongly suggest you use these standard URIs. In fact, your TLDs should automatically be mapped to these URIs by the container without you having to specify anything in web.xml (see JSP.7.3.4ff in the JSP specification)! This feature can be temperamental, though, and hasn't always worked for me. Still it's worth a try, less work to do is always good

- Peter
13 years ago
It is plausible.

- Peter
13 years ago
$amount / 100

- Peter
13 years ago

Originally posted by David Hibbs:
a) If you have to turn it on twice to get the asserts to work (compiler AND runtime), who will really take the time use it?

I'm not sure I get you. What do you mean with turning it on at compile time? Using the -source 1.4 option to indicate that you're happy writing JDK 1.4 specific source? But surely that's a one-time thing; ten seconds of setup in a build script or development environment. Who cares about that kind of time?

Having to enable them at run time is exactly the point of assertions, of course.

b) If you're going to write assumption checks, why be lazy?

What do you mean?

c) It's simply a throwback to C days. [...] Because you can use assert anywhere without regard to putting thought into where the exception will go, who will handle it, or what the result will be, the more assertions there are the more unstable the software is (barring a).

That'd simply be misuse of Java assertions. They are a development and testing tool. If you want to keep your checks around in production, use plain old Java code and think carefully about how you are going to handle them. I don't see how this is a problem with the assertion facility.

[...] In C, assertions were used because there was no other good way to handle an error condition. In C++ and Java, we have these things called "Exceptions".

This remark I don't understand at all. An assertion is just a fancy way to throw an exception (well, an Error actually). Not sure what your point is here, unless it would be that you do want your checks to always run, including in production. If that is what you want, then assertions are simply not the tool for it! You seem to be blaming a screwdriver for being poor at hammering nails into the wall. We've had hammers for that since JDK 1.0...

If an assumption is invalid, throw as SPECIFIC an exception as possible indicating what happened. Put it in the method signature for cryin' out loud, so everyone calling it KNOWS it might blow up.

I could not disagree more. Checked exceptions are not a good way to flag up programming errors. Traditionally, RuntimeExceptions have been used for these (IndexOutOfBoundsException, IllegalArgumentException, etc). Such disastrous errors typically cannot and should not be handled in a fine-grained way, but allowed to bubble up unchecked until some top-level dispatch loop or error handler which can display an error message and/or retry the entire operation. With the assertion facility we've also got AssertionError for testing-only checks which by definition don't need sophisticated handling at all.

I must say I do like assertions a lot. They aren't, and don't want to be, a universal way to check all of your preconditions, postconditions and invariants all the time. They are a straightforward way to embed those checks that are worthwhile to have as testing and documentation, but either too strict or too expensive to perform in production.

- Peter
[ September 09, 2004: Message edited by: Peter den Haan ]
13 years ago

Originally posted by Ajith And Ajith And:
Would it be useful in clustered application server scenarios.... Where the servlets need to be moved around from one server to the other ..

No. The Servlet specification mentions nothing of the kind, and servlets are assumed to be stateless anyway. It's like stateless session beans in the EJB tier: because they are interchangeable you don't need to marshal them across the wire.

Also note that there is no requirement for servlets to be Serializable. The GenericServlet convenience implementation is, but you can implement the Servlet interface yourself.

- Peter
13 years ago
I am more than a bit mystified by

Originally posted by Aziz Dhanani:
I also tried to use "LinkedHashMap" i get the same output.

Are you sure you did that right, Aziz? My suggestion would be to use LinkedHashMap, because it guarantees to preserve insertion order when iterating through the map. It works for me and I wonder why it didn't seem to work for you.

I wouldn't use OrderedMap if a JDK class will do just as well.

- Peter
[ September 08, 2004: Message edited by: Peter den Haan ]
13 years ago
Good suggestion. Still you do have to catch that moronic CloneNotSupportedException (surely that should have been unchecked!) and do something with it; you certainly don't want to throw it away. My suggestion would be to wrap it in an application-specific RuntimeException subclass or even an Error subclass because something must be horribly wrong for this to happen.

Logging shouldn't be an issue, assuming you have some infrastructure at the top of the call stack that logs any unchecked exceptions that propagate all the way up.

- Peter
13 years ago
Don't you think it's fair to say that the majority of JDO users are using it as an ORM tool?

In the "simple ORM" arena, you could consider the Spring JDBC support as a really really simple ORM (hey, it can map query results to objects, it's gotta be ORM ). It's certainly the most lightweight option of the lot.

- Peter
See this thread for the answer.

- Peter
13 years ago
Got the answer. James Duncan Davidson <james.davidson@ENG.SUN.COM> writes:

No, a servlet could be run in a distributed fashion without being serializable as it's the data about sessions and context that has to be
shared.

The interfaces specify serializable so that a servlet can be serialized into a .jar file by a tool and reconsituted later by a servlet engine. This behavior however is not yet well specified.

Makes sense, in a slightly perverted way. I don't think anyone is using this really.

- Peter
13 years ago