Joe Developer

XDoclet 1.2.3 and Listeners in TLDs

I'm a big lover of XDoclet. The 1.2.x stream has been quiet for a while, and I thought I'd read that dev on 1.x had stopped in favor of the rewrite for XDoclet 2. So the issues in 1.2.2 were just there unless you wanted to fix them. The beauty of OSS is that you can fix them - but digging into a lib like XDoclet can be a task.

Many of the issues though, are simply related to a template that needs a tweak. Those are easier to fix assuming some patience. The XDoclet templating syntax is a bit tedious, but is rather clear in its verbosity. I've tweaked a template or 2, or looked at them to understand what's available and how its working when XDoclet In Action and the docs don't address the issue.

So to the crux of the matter - I wanted to generate some mappings for Hibernate Components, and the generation facilities in 1.2.2 didn't quite do the job. My friend Google lets me know there's a new release of XDoclet, so I'll do the upgrade and all will be well - right?

The hibernate mappings for components look perfect, but I'm greeted with a nice stack trace in the browser...

A Listener is failing on startup. A listener that was recently depricated... I look in web.xml - no Listener declaration... Confusion and frustration ensue.

The problem: My listener is showing up in the XDoclet generated TLD.

The JSP 1.2 spec allows Listener declarations in TLDs, but in XDoclet 1.2.2, they weren't generated in the TLD(s). This was "fixed" in XDoclet 1.2.3. The offending code in the XDoclet template:

   <XDtClass:forAllClasses type="javax.servlet.http.HttpSessionActivationListener,javax.servlet.http.HttpSessionAttributeListener,javax.servlet.http.HttpSessionBindingListener,javax.servlet.http.HttpSessionListener,javax.servlet.ServletContextAttributeListener,javax.servlet.ServletContextListener" abstract="false"&th;
      <listener&th;
         <listener-class&th;<XDtClass:fullClassName/&th;</listener-class&th;
      </listener&th;
   </XDtClass:forAllClasses>

Why is this code "offending?" Neither the TLD template nor the web.xml template make a distinction regarding listeners that should or should not be included. Actually, they don't even use the @web.listener tag now... All Listeners are blindly included.

Maybe I'm odd - but I'm all for writing some custom tags in a project and letting XDoclet nicely generate a TLD for the project's tags. In this scenario I'm not shooting for a redistributable taglib - I'm looking for a taglib for this project. If I need to use it again I'll pull it into the utility project we keep internally, but until then it belongs right where it is. As such, listeners that are used for taglib initialization are (were) marked with @web.listener, and generated into web.xml.

Now I admit, I'm lazy. The build target for the web generation is as concise and simple as possible, including **/*Listener, **/*Tag, and the other regulars. With the new template I'm forced to either develop custom tags in a different project (maybe not a bad idea), or contorting my build.xml file to generate the web.xml and TLD artifacts with very specifc filesets...

This too may be a good idea, but is another point of maint... when a new dev adds a Listener, I want them to follow the naming convention and use the appropriate @web.listener tag and trust the code gen system to do the rest of the work. Now I to document, explain, and remember that the files used for these generation tasks have to be explicitly enumerated....


Long story short - if you upgrade to XDoclet 1.2.3, watch out for this one.

Posted at 10:18PM Jul 21, 2006 by saibrian in Gotcha  |