Validation Api usage

Development
1

Hello, I discovered in this PR the usage of javax validation api. I thought it was a very good approach and wanted to try it for a binding I’m currently working on in order to enhance validation handling for configuration and dto classes.

I see no specific dependency in the pom.xml of this PR and apparently jakarta.validation-api is already a dependency in openhab-core. Thought, well, it will be easy to give it a try.

I messed around in my pom.xml adding some variations of :

<dependencies>
  <dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-validator</artifactId>
    <version>6.2.0.Final</version>
</dependency>
<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-validator-annotation-processor</artifactId>
    <version>6.2.0.Final</version>
</dependency>
<dependency>
    <groupId>jakarta.validation</groupId>
    <artifactId>jakarta.validation-api</artifactId>
    <version>2.0.2</version>
</dependency>
</dependencies>

and feature.xml :

		<bundle dependency="true">mvn:jakarta.validation/jakarta.validation-api/2.0.2</bundle>

but without any success to have it functioning.

I end up with this error :

20:43:28.483 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 
javax.validation.NoProviderFoundException: Unable to create a Configuration, because no Jakarta Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath.

Can someone more skilled on dependencies handling give me a hint ?

2

Validation and also other Java EE specs have very specific nature which doesn’t play very well with OSGi. Main reason why - you use a specification API class/factory type to locate an implementation of it. This works well with MTEA-INF/services and flat classpath, but fails miserably with OSGi and isolated classloaders.

For this reason there are various ways of solving the trouble. One which attempts to use bytecode wiring, is Apache Aries SPI-fly. The other one is use of “geronimo specs” bundles. Each of geronimo specs JARs have a small portion of code (called locator) which is ported across various Java EE specifications to find corresponding implementer. This is really the key to get it working with little effort.
If you go by this path, pick geronimo-validation_1.1_spec, then you can use any validation provider. Whole work will be made by spec locator.

Long time ago I made an example on how to get validation specs into Karaf, have a look on it:
https://github.com/code-house/karaf-validation. This is an old example which is based on “old” spec, before transition of JEE to Eclipse foundation, yet it should get you an idea where to look at.

Best,
Łukasz

1 Like
3

Thanks for your detailed answer. My question is in fact : how can this work in openhab-core and why not in openhab-addons. @AndrewFG

4

If you would ask me… there is ConfigStatusProvider (or similar SPI) which is called upon config change with clear purpose.
You can call spec validation provider against configuration DTO and then map constraint violations to config status.

5

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.