You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Karr, David" <Da...@wamu.net> on 2003/02/27 19:31:39 UTC
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.
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.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Investigating adding custom ant task to valid TLD attributes bean mappings
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
oops... my last message should have had this appended:
[1] http://www.ehatchersolutions.com/JavaDevWithAnt
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Investigating adding custom ant task to valid TLD attributes bean mappings
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
On Thursday, February 27, 2003, at 02:24 PM, Craig R. McClanahan wrote:
> 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.)
There are no issues with Ant that prevent a custom task from being
compiled *and* used in the same build process. My JavaDevWithAnt [1]
project does this quite successfully with a custom Lucene <index> task.
And task JAR's are *not* needed in ANT_HOME/lib generally speaking. It
can be convenient (or a burden) for them to be there. Just point the
classpath used with <taskdef> to where the libraries are (including any
dependencies the task needs too!).
It should be a last resort exception to have to put JAR files in
ANT_HOME/lib.
> I would love to have a gadget like this for *all* of my tag libraries
> ...
Again... XDoclet! Get with the program folks! :))
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Investigating adding custom ant task to valid TLD attributes
bean mappings
Posted by "Craig R. McClanahan" <cr...@apache.org>.
See intermixed.
On Thu, 27 Feb 2003, Karr, David wrote:
> Date: Thu, 27 Feb 2003 10:31:39 -0800
> From: "Karr, David" <Da...@wamu.net>
> Reply-To: Struts Developers List <st...@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
Re: Investigating adding custom ant task to valid TLD attributes bean mappings
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
On Thursday, February 27, 2003, at 02:45 PM, Craig R. McClanahan wrote:
>> First of all... why not use XDoclet to generate TLD files in the first
>> place? They you are guaranteed to have valid accurate TLD files.
>>
>
> In general, this is a very useful approach. In the case of Struts, we
> start from an XML document for each TLD because we generate the tag
> library reference document (HTML) and the TLD from the same source
> file.
XDoclet could generate the docs from the source code also. Look at
what I've done with Ant's documentation (currently a proposal, not part
of Ant yet - see link in previous e-mail). If you needed to merge in
examples or something that should not be in the code.... no problem
either. Simply write an XDoclet template for the XML you want
generated and use the <template> subtask.
My JavaDevWithAnt project has an example of this too, generating a
.properties file using a custom template.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Investigating adding custom ant task to valid TLD attributes
bean mappings
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 27 Feb 2003, Erik Hatcher wrote:
>
> First of all... why not use XDoclet to generate TLD files in the first
> place? They you are guaranteed to have valid accurate TLD files.
>
In general, this is a very useful approach. In the case of Struts, we
start from an XML document for each TLD because we generate the tag
library reference document (HTML) and the TLD from the same source file.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Investigating adding custom ant task to valid TLD attributes bean mappings
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
First of all... why not use XDoclet to generate TLD files in the first
place? They you are guaranteed to have valid accurate TLD files.
But, more below...
> 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.
No, it doesn't. You just <taskdef> it after its compiled, not before.
> 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.
Just throw an exception from main and it should fail the build. If you
are sure you are doing a fork="true" you could call System.exit(), but
if you don't fork then you'll kill Ant without a warning.
> 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.
Again, XDoclet to the rescue!
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org