You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Rory Douglas <ro...@oracle.com> on 2009/01/19 23:44:38 UTC

JSP tag files

I've been experimenting with using JSP 2.0 tag files with Sling and have 
run into a few quirks that I thought were worth sharing.  I am hoping to 
use tag files as an alternative to <sling:include> for small pieces of 
standardized content (like a consistent date output style, or link 
display).  With <sling:include> I might need to create 
SyntheticResources with resource types like standard/ui/date to do the 
same thing (alternative suggestions welcomed :-)

The way I've found to get tag files to work is to create a WEB-INF/tags 
directory under my Maven resources directory, and then configure the 
/WEB-INF path as a bundle resource.  This actually works great, and the 
tag files are also picked up by the Eclipse JSP editor.  The 
disadvantages are you have to redeploy your bundle to update the tag 
files; and there could be conflicts between bundles with identical tag 
file names (not sure what the bundle resource provider does in this case?)

However, ideally, I'd like to be able to store these .tag files in the 
repository, much like my resource type scripts, or other static 
resources, and update them using WebDAV or cURL.  The problem here is 
that the JSP compiler requires that tag files come from only 2 places 
(and their subdirectories): /WEB-INF/tags; or /META-INF/tags, if you 
have a JAR-based TLD containing a <tag-file> element.  Unfortunately, 
you can't post content to /WEB-INF or /META-INF since they're protected 
by the web container itself :-(

Lastly, you also can't use the /META-INF .tld method with a <tag-file> 
element due to the way Sling handles bundle TLDs.  The bundle listener 
that registers them reports the location of a TLD as if the JSP page 
referenced the .TLD file directly, even though you actually use the uri 
attribute to reference it indirectly.  This means the JSP compiler 
doesn't keep track of the JAR file where the TLD comes from, and so 
later has no way of finding the associated .tag files contained in it.  
This might be fixable by having the SlingTldLocationsCache object return 
the TLD location info as if the TLD is a JAR entry in the bundle JAR (if 
and only if the TLD contains a <tag-file> element), but I'm not sure 
it's worth it since deploying tag files from /META-INF is no more 
convenient than the /WEB-INF method.

Regards,
Rory