[bv-dev] [BVAL-251] Improve Bean Validation support for modularized environments

Tue Nov 1 16:16:22 EDT 2011

> What does not work today in the following code in a modular environment?
>
> Validation
>     .byDefaultProvider()
>         .providerResolver( myOSGiResolver )
>      .configure()
>      .buildValidatorFactory();

An OSGi-aware resolver is the way to go, but I was wondering who would
build such a resolver. Besides the resolver there would also some glue
code/meta data be required on the BV provider side registering with
the resolver.

We could leave this to end users, but IMO it would be advantageous if
there was a publicly available resolver which just everyone could use.
This was the idea behind having an bv-api-osgi.jar. Any BV
implementation interested in being usable under OSGi could register
itself with that module.

Another question is how custom validators are registered within a
modular environment (e.g. a custom validator for @Past). A module
providing such a validator could contain a constraint mapping for it,
but under OSGi there is AFAIK no way to reference this mapping file
from validation.xml contained in another module. So users of the
custom validator would have to create a constraint mapping file on
their own. This could be circumvented if the bv-api-osgi.jar would
define an "extension point" to which constraint libraries could
contribute their validators.

It also might be useful to have an OSGi-aware resource bundle locator
mechanism which defines an extension point to which constraint
libraries could contribute their message bundles.

All in all I'm unsure whether we should define these things in the
spec. Maybe it would be more appropriate to provide this in separate
project, but it's certainly a field where some improvements would be
beneficial.

--Gunnar

2011/11/1 Emmanuel Bernard <emmanuel at hibernate.org>:
> Two points.
> CDI will be a dependency of Bean Validation (see topic on injection).
> What does not work today in the following code in a modular environment?
>
> Validation
>
>     .byDefaultProvider()
>
>         .providerResolver( myOSGiResolver )
>
>      .configure()
>
>      .buildValidatorFactory();
>
>
> On 31 oct. 2011, at 17:13, Gunnar Morling <gunnar.morling at googlemail.com>
> wrote:
>
> So all JARs must be OSGi-ified before they can be used? [...]
>
> I'm asking because declaring dependencies means that all dependent JSRs (and
>
> the JDK) will need to be OSGi-ified as well. I'd rather see that coordinated
>
> by the Java EE expert group.
>
> In case of BV we would have to add the OSGi headers to the JAR to make
> it usable under OSGi. As Kevin says there is no relation to the JDK
> here, and AFAIK the BV API doesn't have any other additional
> dependencies. So adding these headers wouldn't be a problem IMO (each
> OSGi bundle is still a standard JAR which can be used in any other
> environment).
>
> Another thing is the bootstrapping, i.e. how BV implementations are
> found. Searching for resources such as
> META-INF/services/j.v.ValidationProvider doesn't work in OSGi (I don't
> know about JBoss modules). This kind of things is in OSGi typically
> solved using services, that means in the BV bundle would be the
> definition of a service interface (we already have this with
> ValidationProvider) while BV providers would register implementations
> of this service. In the BV API Jar we still would need some glue
> code/meta-data to obtain references to these implementations.
>
> Personally I feel adding the headers would be ok for the "official"
> API Jar as it's rather un-intrusive, but the bootstrapping stuff might
> be too much. One idea might be to provide separate "enabler" modules
> for the different module systems around, e.g. there could be a
> bv-osgi.jar which takes the raw API jar and makes it usable under OSGi
> (it could also offer j.v.Validator as OSGi service etc.).
>
> --Gunnar
>
> 2011/10/28 Emmanuel Bernard <emmanuel at hibernate.org>:
>
> So all JARs must be OSGi-ified before they can be used? Is there any way to
>
> keep this information outside? Do you know of any other JSR published JAR
>
> that also expose its OSGi headers?
>
> I'm asking because declaring dependencies means that all dependent JSRs (and
>
> the JDK) will need to be OSGi-ified as well. I'd rather see that coordinated
>
> by the Java EE expert group. There is also the problem of supporting them
>
> forever(tm).
>
> On 27 oct. 2011, at 22:52, Kevin Pollet wrote:
>
> Hi experts,
>
> IMHO, making Bean Validation ready for the modular world is a great thing!
>
> A first step might be to provide the module meta-datas (OSGi headers,
>
> …). For OSGi, those meta-datas can be added to the jar Manifest within the
>
> maven build with the maven-bundle-plugin. The advantage is that the api can
>
> be deployed in an OSGi container out of the box. For JBoss Modules the
>
> descriptor reside alongside its content but we can provide it.
>
> WDYT?
>
> --Kevin
>
> _______________________________________________
>
> beanvalidation-dev mailing list
>
> beanvalidation-dev at lists.jboss.org
>
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
>
> beanvalidation-dev mailing list
>
> beanvalidation-dev at lists.jboss.org
>
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>