See intermixed. On Thu, 27 Feb 2003, Karr, David wrote:
> Date: Thu, 27 Feb 2003 10:31:39 -0800 > From: "Karr, David" <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Investigating adding custom ant task to valid TLD attributes > bean mappings > > 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. > 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'd be glad to avoid writing an Ant task and just execute "java" in the > build, but I can't figure out how I can make what happens in the > execution of my class to cause the build to fail. > > Note that I'm only referring to the Struts-EL build, although it's > conceivable we could also do this in the main build. It's still > possible to mess up the "property name"->"setter" mapping, even if you > just use the standard mapping. Catching the error at build time might > save someone a few minutes. > > Testing for this could be done in unit testing, but the entire unit test > suite is not normally done as part of the build, because it takes too > long. This task would go pretty quickly, so it wouldn't be painful to > have it as part of the default build. > I would love to have a gadget like this for *all* of my tag libraries ... Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
