Package org.eclipse.jetty.osgi.boot.jasper

Class JSTLBundleDiscoverer

java.lang.Object
org.eclipse.jetty.osgi.boot.jasper.JSTLBundleDiscoverer
All Implemented Interfaces:
org.eclipse.jetty.osgi.boot.utils.TldBundleDiscoverer
public class JSTLBundleDiscoverer extends Object implements org.eclipse.jetty.osgi.boot.utils.TldBundleDiscoverer
JSTLBundleDiscoverer Fix various shortcomings with the way jasper parses the tld files. Plugs the JSTL tlds assuming that they are packaged with the bundle that contains the JSTL classes.

Pluggable tlds at the server level are handled by ContainerTldBundleDiscoverer.

  • Constructor Details

    • JSTLBundleDiscoverer

      public JSTLBundleDiscoverer()

  • Method Details

    • getUrlsForBundlesWithTlds

      public URL[] getUrlsForBundlesWithTlds(org.eclipse.jetty.deploy.DeploymentManager deployer, org.eclipse.jetty.osgi.boot.utils.BundleFileLocatorHelper locatorHelper) throws Exception
      The jasper TldScanner expects a URLClassloader to parse a jar for the /META-INF/*.tld it may contain. We place the bundles that we know contain such tag-libraries. Please note that it will work if and only if the bundle is a jar (!) Currently we just hardcode the bundle that contains the jstl implemenation. A workaround when the tld cannot be parsed with this method is to copy and paste it inside the WEB-INF of the webapplication where it is used. Support only 2 types of packaging for the bundle: - the bundle is a jar (recommended for runtime.) - the bundle is a folder and contain jars in the root and/or in the lib folder (nice for PDE development situations) Unsupported: the bundle is a jar that embeds more jars.
      Specified by:
      getUrlsForBundlesWithTlds in interface org.eclipse.jetty.osgi.boot.utils.TldBundleDiscoverer
      Returns:
      array of URLs
      Throws:
      Exception - In case of errors during resolving TLDs files