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

Emmanuel Bernard emmanuel at hibernate.org
Tue Nov 1 10:36:24 EDT 2011


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20111101/f29ae5b3/attachment.html 


More information about the beanvalidation-dev mailing list