#37 Load taglibs from the classpath


At the moment it is not possible to load taglibs from outside the webapp root, this could be a problem for example in:
- development: from inside Eclipse the taglibs are not seen and one is forced to copy them inside WEB-INF/lib
- production: if endorsed libraries are in use then they are not seen

The goal is to load taglibs from the classpath, replacing the current method, which loads taglibs only from the webapp root.
This patch has been adapted from Manuel Molaschi's (https://sourceforge.net/tracker/index.php?func=detail&aid=2954132&group_id=794&atid=100794) to fit the current class.

Testing has been done on Ubuntu 11.04 and Windows 7, using Tomcat 6 as application server.


  • lazywithclass

    This patch targets TaglibFactory.java at revision 1559, it has been created with svn diff in the leaf package

  • Are you saying that this will find the taglibs on all places where it did in 2.3.18, with the same priorities (backward compatibility!), and if it didn't found the taglib that way, then it will try to find it in the classpath?

  • lazywithclass

    At least, this would be the big plan...
    The web.xml loading is left untouched, the change is on the /lib loading, that searches the classpath instead of searching only the lib folder, and the fall back to the hard-coded path is left as well.
    I think the part that searches all .tld files in /WEB-INF is missing at the moment, I was not sure if such a search was correct in J2EE specs, but it's easy to restore.
    I admit the patch is not optimal, because some of the code could be simplified using StringUtils, FileUtils and a few other form apache commons, but I simply copied those methods to avoid adding dependencies. Also there could be some improvement and refactoring for the internal objects, that should store a few extra info to avoid a double parsing. Nonetheless the patch is working, if you want to try it and tell if there is some improvement you'd like, I'll try my best to do it.

  • Not using Apache commons (or other dependencies) was the right thing for FreeMarker.

    Otherwise, the situation is this:

    (a) The 2.3.x series must keep backward compatibility (even if it goes against the J2EE specs), because the jar should be a drop-in replacements, even from system integration standpoint. (Whenever it wasn't so, it was considered to be a bug.) Changes that are compatible with the J2EE specs but not with 2.3.x can only be added to 2.4.x.

    (b) I don't know the internals of the JSP-related part of FM very well (or of any other parts for that mater), and I'm afraid that the author won't be available for this. However, I'm willing to integrate patches and fix bugs, but it's a unpaid effort for me and I'm not sure if and when I find time for it. So it would help matters if this patch is in as good shape as possible. Even then I might as well will be a chicken, and just add it to 2.4.0 (not to be confused with 3.0.0), where minor compatibility breakages are expected anyway.

    (c) Currently, accepting patches require Contributor's License Agreement (just the usual stuff), sent signed with snail-mail. I suppose if it will look like that this patch makes into a release, we can arrange that.