struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Investigating adding custom ant task to valid TLD attributes bean mappings
Date Thu, 27 Feb 2003 19:24:52 GMT
See intermixed.

On Thu, 27 Feb 2003, Karr, David wrote:

> Date: Thu, 27 Feb 2003 10:31:39 -0800
> From: "Karr, David" <David.Karr@wamu.net>
> Reply-To: Struts Developers List <struts-dev@jakarta.apache.org>
> To: struts-dev@jakarta.apache.org
> 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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Mime
View raw message