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.

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

One other quick note – it seems somewhat inconsistent to recognize the listerner element but not the tag library URI ... probably better to process either both or neither.

Updated to glassfish build SJSAS-9_1-B27-EA-07_Dec_2006 which fixes this problem.