Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable 3rd party to handle violations #16

Merged
merged 7 commits into from Jul 9, 2017

Conversation

codecholeric
Copy link
Collaborator

This adds an API for 3rd party clients to access information about violations.
Up to now, rule.evaluate(classes) didn't give a lot of useful information to react to violations, e.g. for drawing some kind of external report, etc.
Now it's possible to react to certain types of objects, contributing to a violation, like JavaFieldAccess, etc.
The first draft of the API can be used the following way

ArchRule rule = noClasses().should().accessField(System.class, "out");
EvaluationResult result = rule.evaluate(classes);
result.handleViolations(new ViolationHandler<JavaFieldAccess>() {
    @Override
    public void handle(Collection<JavaFieldAccess> violatingObjects, String message) {
        // handle field accesses causing a violation
    }
});

The handler will be notified about all objects of an assignable type, i.e. ViolationHandler<JavaAccess<?>> will be notified about all violations any JavaAccess contributed to, ViolationHandler<JavaMethodCall> will only be notified about violations caused by method calls.

…th parameter <T>, however, that parameter got lost by some raw conversion in the middle, thus the parameter was always useless, by the time one could access it from ConditionEvents. The parameter T would really only have made sense, if in the end it would have resulted in ConditionEvents<T>, where all events have the same type of corresponding objects. This on the other hand would have made it impossible, to add a ConditionEvent<JavaMethod> to the events, so it would have caused another refactoring, aggregating all ConditionEvent<JavaMethod> into one ConditionEvent<JavaClass>. In the end I decided that the type parameter wasn't worth the trouble, nor the bloat, and removed it (the future will reveal, if this was the right decision).
…n now pass a ViolationHandler to ConditionEvents and handle all events matching the respective handler method. I.e. one could supply a ViolationHandler<JavaAccess<?>> and would get all events passed that are reported with respect to a JavaAccess<?> (i.e. have a corresponding object of type JavaAccess<?>)
…to test correct dispatching of violations to supplied violation handler.
- support for multiple corresponding objects (since some violations are created by a set of objects)
- handling is now further dispatched to ConditionEvent, to enable different events to report themselves differently
@codecholeric codecholeric self-assigned this Jul 9, 2017
@codecholeric codecholeric added this to the Release 0.5.0 milestone Jul 9, 2017
@codecholeric codecholeric merged commit 870c0f8 into master Jul 9, 2017
@codecholeric codecholeric mentioned this pull request Jul 9, 2017
@codecholeric codecholeric deleted the enable-3rd-party-to-handle-violations branch July 15, 2017 20:49
codecholeric added a commit that referenced this pull request Feb 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant