refactor validation of generic_resolver rules to startup

[dtrai2]

• Move validation logic to __attrs_post_init__ in GenericResolverRule.
• Remove redundant error handling in GenericResolver processor.
• Update corresponding tests to reflect changes.

[djkhl]

looks good and works as expected :)

[ppcad]

Getters need to be updated on the fly in the generic resolver. They are going to be refreshed periodically to get updated data from the HTTP getter.
Therefore, raising a configuration error leads to problems, since this can happen when Logprep is already running.
I'm going to create a pull request for this.

[dtrai2]

Getters need to be updated on the fly in the generic resolver. They are going to be refreshed periodically to get updated data from the HTTP getter.
Therefore, raising a configuration error leads to problems, since this can happen when Logprep is already running.
I'm going to create a pull request for this.

but isn't it already working with the general config refresh we have in Logprep? That way the configuration is also reloaded periodically and in case an exception is thrown, Logprep will continue running with the previous configuration.

[ppcad]

Getters need to be updated on the fly in the generic resolver. They are going to be refreshed periodically to get updated data from the HTTP getter.
Therefore, raising a configuration error leads to problems, since this can happen when Logprep is already running.
I'm going to create a pull request for this.

but isn't it already working with the general config refresh we have in Logprep? That way the configuration is also reloaded periodically and in case an exception is thrown, Logprep will continue running with the previous configuration.

Oh, you are right, it does that. Last time I checked I've gotten an error when I raised a configuration error. I must have made a mistake then.

However, as far as I know, a config refresh can't detect changes in HTTP getters, so it won't reload.
Furthermore, relying on a reload would require to reaload the whole config.
What I have done now is make the resolver refresh getters only.
This would require some form of _ensure_rules_from_file again.
I suppose I could make it raise a warning and retain the old getter values on failure.
What do you think about this?

[ekneg54]

What I have done now is make the resolver refresh getters only.

We should avoid implementing special mechanics in favor of get a solution for the config refresh. I think it is better to solve the problem in the config refresh that configs behind getters gets evaluated too on config refresh.

yes I see, that the fix here could be very easy. but if we have a lot of these easy fixes again it will be hard to implement global mechanics again.

[dtrai2]

as discussed offline we can merge this pull request and then find a solution for loading external resources (that are not rule configurations) later.