[dsurber]

This message has not been recovered.

[Riyad Kalla]

This message has not been recovered.

[dsurber]

This message has not been recovered.

[Riyad Kalla]

This message has not been recovered.

[dsurber]

I identified the problem with JSP and JSTL. Getting the right versions is not enough. You also have to get them in the right place. After much fooling around I got the correct versions of jsp-api.jar, jstl.jar, standard.jar, and servlet-api.jar all in the right place. For a Spring app it appears that all four must be in $catalina-home/common/lib. No big surprise there. It also must be the case that those jars appear only in common/lib. They cannot appear in WEB-INF/lib as well, otherwise you get two versions of the same class and some ClassCastExceptions.

Still, no great shock. Where it gets interesting is that jsp-api.jar and servlet-api.jar must also be in the build path for a Spring web app. Now here is the problem. I have a bunch of jars in the build path that must be deployed to WEB-INF/lib for the app to run, but I also have these two, jsp-api.jar and servlet-api.jar that have to be in the build path but cannot be in WEB-INF/lib. I’m too lazy to configure all the deploy stuff by hand, so what I did was put all the stuff that has to be deployed into a library and the two that are not deployed as separate jars. Then I set the deploy params to deploy included libraries but not jars. Convoluted, but it works.

Douglas

[Riyad Kalla]

This is actually a typical approach to working around the problem of needing the J2EE jars at build time but not deployment time, that’s why we offer so many deployment flags.

[Author]

Posts