Details
Bug
Resolved
Major
Description
Section JSP.7.2.1 of the JSP 2.1 specification requires that JSP containers recognize TLD files that are embedded in the META-INF directory of a JAR file that is contained in the WEB-INF/lib directory. Jetty is not recognizing such a TLD in the case of the MyFaces 1.1 implementation JAR (myfaces-impl-1.1.4.jar), even though the error message that you receive implies that the JAR files have been checked.
An example of this problem is described by a thread on the jetty-support mailing list at <http://www.nabble.com/-Jetty-support--Jetty-6-and-JSF-taglibs-problems-t2613645.html>.
Activity
Hello Craig.
Jetty itself will scan correctly (I believe) for tlds but only to find and initialize the <listener> elements. The issue I think is that Jetty uses Glassfish's jsp module which expects to use JSF tlds ONLY from the system classpath as Glassfish is a JavaEE container. So, as Glassfish is a JavaEE container and also JSF1.2, then it isn't going to accept JSF1.1 tlds in the webapp classpath.
I need to contact the Glassfish guys and see what would be the best way to approach this. Having not inconsiderable experience in this area yourself, do you have any suggestions? 
regards
Jan
Best way to contact the Glassfish developers would be on the Glassfish Developers list at java.net . Mailing list info is at <https://glassfish.dev.java.net>.
That being said, Glassfish does indeed have this restriction because it is a Java EE 5 implementation, which is required to ignore any JSF application that is present in the webapp itself. But, AFAICT, Jetty doesn't aspire to do that (implement all of Java EE 5), so you are not bound by that requirement – you are perfectly free to recognize either a JSF 1.1 or a JSF 1.2 implementation found inside WEB-INF/lib. Not doing so (forcing developers to put the implementation on the container's shared classpath) could even be considered a competitive disadvantage to servlet containers like Tomcat, which do this just fine.
Craig
Further research indicates that the actual problem might be slightly different than what is described above. It seems that the TLD might actually getting scanned (for example, the <listener> element inside the TLD is processed. So the actual problem is likely to be just that TLD URIs inside a scanned TLD are not being recognized.