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@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@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@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@lists.jboss.org
> > > >
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > > >
> > > >
> > > > _______________________________________________
> > > > beanvalidation-dev mailing list
> > > >
beanvalidation-dev@lists.jboss.org
> > > >
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > > >
> > > >
> > >
> > > _______________________________________________
> > > beanvalidation-dev mailing list
> > >
beanvalidation-dev@lists.jboss.org
> > >
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > >
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> >
beanvalidation-dev@lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> >
beanvalidation-dev@lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
>
beanvalidation-dev@lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev