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.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.
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.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.
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?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 .
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?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?
What do you mean?b) If you're going to write assumption checks, why be lazy?
![]()
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.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).
[...] 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".
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.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.
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.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 ..
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 meOriginally posted by Aziz Dhanani:
I also tried to use "LinkedHashMap" i get the same output.
Makes sense, in a slightly perverted way. I don't think anyone is using this really.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.