commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Casey <>
Subject [Jelly] [PROPOSAL] alternate taglib loading mechanism
Date Fri, 19 Sep 2003 00:09:32 GMT
Sorry this is a long email, but it might be interesting enough to
read...I dunno...


I've just had a minor breakthrough on a xml parsing framework that I'm
completing, and I feel like I owe it to the Jelly folks to share.

I've taken a page or six from both JSP and Jelly taglibs in writing this
xml parser.  It uses a tag-driven approach to register interest in
certain types of nodes, and then register a "callback" class. Also - and
thank you all so much for this - it parses namespace declarations to
dynamically load new taglibs off of the classpath. However, this is
where the epiphany took place.

For months, I've been using an implementation of the Jar specification
service loader (like the one in commons-discovery) to find service
implementations and automagically load the correct one.  For those of
you with quizzical expressions, this amounts to reading a file under
META-INF/services, which is named as the fully-qualified class name for
the service interface, and performing Class.forName() on the first line.

So this brought up a good point in my mind: Jelly has a registered set
of "native" taglibs pre-mapped in a properties file, right?  Anything
else has to be specified as the fully-qualified class name of the tag
library class in order to be used in a script. Why?

Instead, why not create a file under META-INF/parsers called
my-namespace.jtl (jelly-tag-library), and reference it from a script
with jtl:my-namespace (or jelly:my-namespace, if you prefer).  Then,
it's a simple matter of reading the file from the
ClassLoader.getResourceAsStream() input, and parsing it using a dynalib
(like dynatag, thanks again Jelly) to create a "headless" taglib for

This technique allows me to embed the tag library definition in my
parser library jars, have a dynamic list of available parsing libraries,
and still refer to each with a terse namespace notation...

Anyway, take or leave it. :)



View raw message