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

Sorry for the long slack off. OSGi is generally not my field but here are a few comments on what Gunnar and Kevin have said: - we can definitely experiment with Hibernate Validator and offer some OOTB support for OSGi and other modularity solutions. - we can consider the API JAR provided by the RI team and add the OSGi headers if that's the correct solution but I don't feel like adding them in the spec document proper - we should align with what the CDI group does wrt OSGi headers especially since CDI will be an optional dependency of BV - can someone flesh out a more concrete proposal and push it to http://beanvalidation.org/proposals/BVAL-251 ? Kevin do you want to take the lead? Emmanuel On 3 nov. 2011, at 12:13, Kevin Pollet wrote: > Hi, > > On 1 November 2011 15:36, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; > wrote: > 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(); > > > The dependency to CDI will be optional, right? > > > In this case that dependency should be declared as optional in the > OSGi headers. By doing that, if CDI cannot be used in an OSGI > environment this will not affect BV. > > > AFAIK, the following things doesn't work with that approach (not > exhaustive): > > > * loading of validation and constraint mapping files > * loading of ValidationMessages.properties > * I've not tested it but I think the loading of the class specified > in the xml files doesn't work > > > The problem here is that the implementation use the TCCL or the > classloader of one of its class to load resources or classes. That > approach cannot work in a modular environment. For example in OSGi > the TCCL is not set to the right classloader and the implementation > classloader can't access another bundle resources or classes (if > they are not imported). > > > IMHO, BV should specify a mechanism used by implementations to load > resources and classes. The default implementation should work out of > the box in Java EE and this mechanism can be customized by users > which want to work in a modular environement. > > > Maybe an implementation of such mechanism can be provided for OSGi > or JBoss modules by the RI? > > > WDYT? > > > --Kevin > > > On 31 oct. 2011, at 17:13, Gunnar Morling > <gunnar.morling(a)googlemail.com&gt; 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(a)hibernate.org&gt;: > > > 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(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > > > > > > > _______________________________________________ > > > beanvalidation-dev mailing list > > > beanvalidation-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > > > > > > > > _______________________________________________ > > beanvalidation-dev mailing list > > beanvalidation-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev