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

Jagadish Prasath Ramu jagadish.ramu at oracle.com
Mon Jan 9 10:02:11 EST 2012


Hi Emmanuel, Kevin :

Please find a reference on defining OSGi header and version numbers in
the manifest file of api .jars. 

https://wikis.oracle.com/display/GlassFish/Maven+Versioning+Rules

Thanks,
-Jagadish

On Mon, 2012-01-02 at 17:47 +0100, Emmanuel Bernard wrote:
> 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 at hibernate.org>
> > 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 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
> >         
> > 
> > _______________________________________________
> > 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





More information about the beanvalidation-dev mailing list