[bv-dev] [BVAL-251] Improve Bean Validation support for modularized environments
Kevin Pollet
kevin.pollet at serli.com
Mon Jan 9 10:14:08 EST 2012
Thanks for the link.
--Kevin
On 9 January 2012 16:02, Jagadish Prasath Ramu <jagadish.ramu at oracle.com>wrote:
> 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
>
>
>
> _______________________________________________
> 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/20120109/adb23c55/attachment-0001.html
More information about the beanvalidation-dev
mailing list