You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One more issue I've found when trying to integrate db-scheduler into our project: we're using Spring Boot and so I opted for the db-scheduler-spring-boot-starter dependency (convenient!). I was surprised, however, that by simply adding the dependency caused the application to fail during startup. The error looked like this:
***************************
APPLICATION FAILED TO START
***************************
Description:
The Bean Validation API is on the classpath but no implementation could be found
Action:
Add an implementation, such as Hibernate Validator, to the classpath
containing no clue why that has suddenly become a problem.
I did eventually find out that it is caused by the @Validated annotation on the DbSchedulerProperties class. It turns out that the presence of this annotation makes Spring try to load a bean validator which we simply don't have in the project. This is confusing because there's no mention or indication that the db-scheduler-spring-boot-starter needs a bean validator to work properly.
I think this should be mentioned in the README or somewhere so that people know they need to have a bean validator in the classpath to make things work. On the other hand, what I would appreciate even more would be if the library did not depend on it at all. If I'm not mistaken, it seems to be used only in that one class and just to validate that some properties are @NonNull. In my opinion, that doesn't really justify usage of such a library. For example in our case it would mean bringing the validator dependency (~ 1.2 MB) just for this one use-case.
I'm happy to remove the dependency myself and send a PR if you'd be willing to accept it 馃檪
The text was updated successfully, but these errors were encountered:
I agree. Let's remove @Validated and the explicit (provided) dependency on hibernate-validator. There is a few other validation mechanisms built-in (e.g. converting durations and parsing booleans) as well as mechanisms built by @kagkarlsson. Should be safe, but has to be mentioned in the release notes.
By the way, a great issue description @dmoidl 馃憦馃徎
Hi @kagkarlsson 馃憢
One more issue I've found when trying to integrate
db-scheduler
into our project: we're using Spring Boot and so I opted for thedb-scheduler-spring-boot-starter
dependency (convenient!). I was surprised, however, that by simply adding the dependency caused the application to fail during startup. The error looked like this:containing no clue why that has suddenly become a problem.
I did eventually find out that it is caused by the
@Validated
annotation on theDbSchedulerProperties
class. It turns out that the presence of this annotation makes Spring try to load a bean validator which we simply don't have in the project. This is confusing because there's no mention or indication that thedb-scheduler-spring-boot-starter
needs a bean validator to work properly.I think this should be mentioned in the README or somewhere so that people know they need to have a bean validator in the classpath to make things work. On the other hand, what I would appreciate even more would be if the library did not depend on it at all. If I'm not mistaken, it seems to be used only in that one class and just to validate that some properties are
@NonNull
. In my opinion, that doesn't really justify usage of such a library. For example in our case it would mean bringing the validator dependency (~ 1.2 MB) just for this one use-case.I'm happy to remove the dependency myself and send a PR if you'd be willing to accept it 馃檪
The text was updated successfully, but these errors were encountered: