[
https://issues.apache.org/struts/browse/SHALE-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_39717
]
Craig McClanahan commented on SHALE-382:
----------------------------------------
I'm quite intrigued by the idea of static analysis to validate the content of a
web application, and would like to target doing some things that actually go
quite a ways beyond what is here already. I think we need at least three
layers of static analysis tools
* Pure servlet based application (looks at WEB-INF/web.xml etc.)
* Servlet+JSP based application (extends servlet based)
* Servlet+JSF based application (extends Servlet+JSP based but
does not complain about no JSP artifacts if you're using something
like Facelets)
In particular, I like the approach you took of making these JUnit test cases
... we can make it trivially simple for a webapp project to include this kind
of thing, no matter whether they are using Ant or Maven or whatever as a build
environment. I'm going to start a "shale-audit" module in the sandbox to
accumulate progress on these ideas, and will seed it with some very basic
tests. Then we can expand as we go.
I've created an umbrella issue SHALE-388 to track this, and will tag this issue
as dependent upon that one.
A couple of specific comments on the tests provided in your patch:
* It is actually legal to have the same tag *name* in two different tag
libraries, as long as the taglib URIs are different.
* The tests should be set up to analyze *all* relevant resources in a
web application (for example, a TLD analyzer should go find TLDs in
all the places that the JSP spec says they can be), rather than
presuming any static list of resources to check.
> Abstract TestCase for testing TLDs
> ----------------------------------
>
> Key: SHALE-382
> URL: https://issues.apache.org/struts/browse/SHALE-382
> Project: Shale
> Issue Type: New Feature
> Components: Test
> Affects Versions: 1.0.4-SNAPSHOT
> Reporter: Dennis Byrne
> Priority: Minor
> Attachments: patch.txt
>
>
> Documentation is in the patch.
> I took Gary's advice on mailing list about eliminating the dependency on
> beanutils; I thought org.apache.shale.util.PropertyHelper would be a good
> place. However the Shale Test project *already* has a dependency on
> beanutils and it *doesn't* have a dependency on Shale Core.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
