alvison / inspektr Goto Github PK

What steps will reproduce the problem?
-----
1. run 'mvn eclipse:eclipse' to generate a .classpath file in
trunk/inspektr-core
2. compare with the committed .classpath file in trunk/

What is the expected output?
the two are nearly identical
-----

What do you see instead?
-----
several entries from the maven generated one are missing from the committed
one. One of the entries prevents Eclipse from compiling the code on a newly
setup environment.

What version of the product are you using? On what operating system?
-----
N/A

Please provide any additional information below.
This bug will not happen if the user has spring-test 2.5 in their maven
repository. In a newly setup environment, the user will not have this file,
and when running 'mvn compile', maven will download spring-test 2.5.1
(specified in inspektr-core/pom.xml). The committed .classpath file in
trunk/ references spring-test 2.5, so Eclipse can't get to the dependency.

In addition to the above issue, here is a list of jars that are in the
maven generated .classpath but not in the committed version:

    <classpathentry kind="var"
path="M2_REPO/org/springframework/spring-aop/2.5.1/spring-aop-2.5.1.jar"/>
    <classpathentry kind="var"
path="M2_REPO/aopalliance/aopalliance/1.0/aopalliance-1.0.jar"/>
    <classpathentry kind="var"
path="M2_REPO/aspectj/aspectjweaver/1.5.3/aspectjweaver-1.5.3.jar"/>
    <classpathentry kind="var"
path="M2_REPO/log4j/log4j/1.2.14/log4j-1.2.14.jar"/>
    <classpathentry kind="var"
path="M2_REPO/aopalliance/aopalliance/1.0/aopalliance-1.0.jar"/>
    <classpathentry kind="var"
path="M2_REPO/org/springframework/spring-context-support/2.5.1/spring-context-su
pport-2.5.1.jar"/>
    <classpathentry kind="var"
path="M2_REPO/org/springframework/spring-web/2.5.1/spring-web-2.5.1.jar"/>

Two of those jars have already been mentioned in Issue #6 in order to get
the tests to run.

Would be helpful if the stats aspect can be configured to use an
application-specific resolver to build the StatisticActionContext, in
particular the stat name, based on the runtime JoinPoint. The current code
can remain the default behavior if no app-specific resolvers are provided.

The JDBC Audit Manager does not currently check the lengths for VARCHARs so
adding something too long could throw an exception.

They should be truncated.

Modify the GreaterThan annotation so that if its set on an array, it will
check every value in the array).

Would be helpful to provide a default resolve that gives the user name. In
some cases, this may be all the the application needs.

What steps will reproduce the problem?
-----
1. run the tests through either Maven or Eclipse

What is the expected output?
-----
Tests pass.

What do you see instead?
-----
Tests fail.

What version of the product are you using? On what operating system?
-----
 N/A

Please provide any additional information below.
-----
in testContext.xml
1. Log4jErrorReporter is referenced but not found in the project. Perhaps
use CommonsLoggingErrorReporter instead
2. JdbcAuditTrailManager's constructor requires a parameter to be passed in
(none are passed in now)
3. AuditTrailManagementAspect's constructor requires 4 parameters (setter
injection is being used instead of constructor injection)

in the .classpath file
1. spring-aop 2.5.1 and aopalliance 1.0 must be added

The tests also require that an Oracle JDBC driver exist on the classpath.

We will use latest Grails-1.0-SNAPSHOT build until 1.0-final is released
some time this month (February 2008)

What steps will reproduce the problem?
1. I put Auditable on a method in a controller bean (defined in servlet xml)
2. I got no error but audit info did not show up

If this should work, please document if there is something special I need
to do.

The provided InMemoryStatisticsManager is currently printing to standard
output. It should use commons logging like the auditing does.

Allow table names to be configurable for environments where naming
conventions are different

This is an inconvenience for running in non-web more (i.e. junit testing).
What steps will reproduce the problem?
1. Add Audible notation
2. Run existing Junit test that calls that method 

- At a minimum, document it.
- Consider by default instantiating a ClientInfo with null IP addresses and
then at least, useful exceptions will be thrown about which attributes are
null.
- or maybe could default to "" (but I realize you may want to flag their
absence)

Gracefully shut down any thread executor services so that any tasks still
in the queue get completed.

Ability to send audit information via JMS.

Allow auditables to reference method parameters

Use statistics annotation to monitor response times of the "actions" that
we are gathering statistics on.  So instead of just number of times per
minute/hour/second we can also gather response times.

Allow auditable to generate multiple audit entries

Create factories to allow people to create Statistic and auditing contexts.
 This is to allow applications that use Async to obtain the information
they need from things other than threadlocals (which work great for non
async access).

Project pulls in a lot of Spring dependencies.  Can we mark as provided?

The statistics module right now will work very well if there is only one
node.  If there are two nodes, and both try and insert a statistics record,
one will succeed and the other will fail and its statistic won't be counted.

Add annotation support for method parameters.