Consider using JDK-Standard 'ServiceLoader' instead of Spring about zally HOT 5 CLOSED

AutoService project can be used for generating config for ServiceLoader from source during compile time. It uses java annotation processor. Very easy to use. Very easy to implement. No dependency from Spring and no classpath walking at runtime.

from zally.

Wow, thanks for this interesting idea and proof of concept 👍

You are totally right, without Spring integrations in other tools should be quite easy. For this we could fledge out the rule evaluation in a library and link this library to the server.

How could #75 be implemented with this approach? We'd like to make rule set configurable on runtime. As far as I understood your code, you have to provide the configuration in manifest file in META-INF.

from zally.

Regarding #75 I could imagine to give every Rule-Implementation a unique id/shortname (think of modules/checks in Checkstyle). Then after loading every rule available in classpath and picked up by ServiceLoader, just filter via standard 'java.util.function.Predicate' and return a new RuleValidator-object containing only filtered rules. That would be the easiest thing to try first.

Which rules to include can be specified by a zally.yaml maybe of if nothing specified, every rule kicks in. In zally.yaml a 'include', 'exclude' section can exists to let the user define what makes sense for him/her.

For going with ids/shortnames it would helpful for a user to build then back-links to specific rules in the report (like in the checkstyle-link above). But I think I've seen something like that already, right?

Regards
Jörg

from zally.

Regarding #75 - I totally agree with @jbellmann, as long as we have full list of Rule implementations we can filter it out by any criteria.

Regarding ServiceLoader mechanism:
I've experimented with this approach. It works fine but there is one substantial downside:
you need to explicitly list all your implementations in separate file (correct me if I'm wrong). Since in our case all implementations are known at compile time there is no value in it. You can simply write code like that:

val allRules = listOf(
  AvoidJavascriptKeywordsRule(),
  ExtractBasePathRule(),
  ...
)

(in fact first version of Zally worked exactly like that). Maintaining such list is proven to be tedious and error-prone in a long run.

If we want to move core validation logic into separate module that doesn't depend on Spring, I would suggest to use same mechanism as in Spring: classpath walking.
Possible implementation could be reflections. Perhaps we could even get rid of annotations and pick any class that implements Rule interface unless the class is marked with @Ignore.

from zally.

Given that:

1. #843 was rejected because it's "re-creating what Spring does already"
2. We make heavy use of Spring AOP in https://github.com/zalando/zally/blob/master/server/src/main/java/de/zalando/zally/util/ast/MethodCallRecorder.kt

It appears that the switch to a Spring-free ServiceLoader mechanism is not happening and this issue can be closed.

from zally.