There's already a precedent for this kind of thing at Jakarta Taglibs. On the front page of the web site:
http://jakarta.apache.org/taglibs/index.html there's even a section for Tool Extensions, currently with only one occupant (an UltraDev plugin). I think this would be a great place for what you are describing. -- Martin Cooper "Karr, David" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] > > On Thu, 27 Feb 2003, Karr, David wrote: > > > From: "Karr, David" <[EMAIL PROTECTED]> > > > > I don't like the fact that it's so easy to mess up my BeanInfo mapping > > in Struts-EL, as it's all validated at runtime through introspection. > > After 1.1 is released, I plan to do some minor rearrangement inside the > > BeanInfo classes and add a custom task to the build which uses a class I > > just wrote which parses a TLD (using Digester) and tries to verify that > > all the tag attributes have valid setter methods in the tag class. > > Is this tool specific in any way to struts-el? It sounds like a generally > useful tool that would work on any TLD. One possible distribution channel > would be to propose it as an add-on utility to Tomcat (or even something > that could be enabled at context startup time -- from bug reports it seems > that WebLogic does this sort of checking). Another avenue would be to > package it as a commons library that could be used by apps relying on > custom tag libraries (like we do), so that anyone could integrate it into > their build process. No, it's not specific to Struts-EL. It's just easier to mess up the mapping in a library that uses BeanInfo. > > The introspection mechanics of this class are relatively > > straightforward, but really putting this into the build presents some > > questions in my mind, mostly Ant-related: > > > > Where should I put the Ant task class? Obviously, it would go in the > > "struts-el" tree, but I'm not sure of the logistics of this. The task > > can only be performed after the library is built, but I guess the task > > class has to be available when ant starts. > > There's a similar chicken-and-egg issue with the custom Ant tasks for > Tomcat integration. What I do is just copy catalina-ant.jar from my most > recent Tomcat build and stick it in $ANT_HOME/lib. I don't try to build > the Ant tasks and immediately use them. (This would be another argument > for releasing this kind of library separately, even if it was struts or > struts-el specific.) I'm convinced that this has wider applicability than Struts-EL, but I don't think the Struts build should be directly dependent on Tomcat (even though I hardly use anything else). This points to a separate "commons-jspantsupport" library, but the scope of that is awfully small. I would guess there are no other tools at this scope. It would look pretty silly to just have the one task in the library. One implementation detail I'm wondering about: When I use the Digester, I apparently need to register a local copy of the taglib DTD (my firewall here is brutal). I guess one of the optional task parameters would be the path to the TLD DTD. Then, there's the question of whether I use the 1.1 or 1.2 DTDs. For the elements this tool is looking at, it doesn't matter, but my "register" call has to match the DTD with the public identifier. Now that I'm thinking about this, perhaps the best place for a tool like this (and others like it) would be in the JSTL implementation? That would muddle the issue for the people still hanging on to Servlet 2.2, but it might be the most appropriate place for it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
