Thanks for the link.<div><br></div><div>--Kevin<br><br><div class="gmail_quote">On 9 January 2012 16:02, Jagadish Prasath Ramu <span dir="ltr"><<a href="mailto:jagadish.ramu@oracle.com">jagadish.ramu@oracle.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Emmanuel, Kevin :<br>
<br>
Please find a reference on defining OSGi header and version numbers in<br>
the manifest file of api .jars.<br>
<br>
<a href="https://wikis.oracle.com/display/GlassFish/Maven+Versioning+Rules" target="_blank">https://wikis.oracle.com/display/GlassFish/Maven+Versioning+Rules</a><br>
<br>
Thanks,<br>
-Jagadish<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, 2012-01-02 at 17:47 +0100, Emmanuel Bernard wrote:<br>
> Sorry for the long slack off.<br>
><br>
><br>
> OSGi is generally not my field but here are a few comments on what<br>
> Gunnar and Kevin have said:<br>
><br>
><br>
> - we can definitely experiment with Hibernate Validator and offer some<br>
> OOTB support for OSGi and other modularity solutions.<br>
> - we can consider the API JAR provided by the RI team and add the OSGi<br>
> headers if that's the correct solution but I don't feel like adding<br>
> them in the spec document proper<br>
> - we should align with what the CDI group does wrt OSGi headers<br>
> especially since CDI will be an optional dependency of BV<br>
> - can someone flesh out a more concrete proposal and push it<br>
> to <a href="http://beanvalidation.org/proposals/BVAL-251" target="_blank">http://beanvalidation.org/proposals/BVAL-251</a> ? Kevin do you want to<br>
> take the lead?<br>
><br>
><br>
> Emmanuel<br>
><br>
> On 3 nov. 2011, at 12:13, Kevin Pollet wrote:<br>
><br>
> > Hi,<br>
> ><br>
> > On 1 November 2011 15:36, Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>><br>
> > wrote:<br>
> > Two points.<br>
> ><br>
> ><br>
> > CDI will be a dependency of Bean Validation (see topic on<br>
> > injection).<br>
> ><br>
> ><br>
> > What does not work today in the following code in a modular<br>
> > environment?<br>
> ><br>
> ><br>
> > Validation<br>
> > .byDefaultProvider()<br>
> > .providerResolver( myOSGiResolver )<br>
> > .configure()<br>
> > .buildValidatorFactory();<br>
> ><br>
> ><br>
> > The dependency to CDI will be optional, right?<br>
> ><br>
> ><br>
> > In this case that dependency should be declared as optional in the<br>
> > OSGi headers. By doing that, if CDI cannot be used in an OSGI<br>
> > environment this will not affect BV.<br>
> ><br>
> ><br>
> > AFAIK, the following things doesn't work with that approach (not<br>
> > exhaustive):<br>
> ><br>
> ><br>
> > * loading of validation and constraint mapping files<br>
> > * loading of ValidationMessages.properties<br>
> > * I've not tested it but I think the loading of the class specified<br>
> > in the xml files doesn't work<br>
> ><br>
> ><br>
> > The problem here is that the implementation use the TCCL or the<br>
> > classloader of one of its class to load resources or classes. That<br>
> > approach cannot work in a modular environment. For example in OSGi<br>
> > the TCCL is not set to the right classloader and the implementation<br>
> > classloader can't access another bundle resources or classes (if<br>
> > they are not imported).<br>
> ><br>
> ><br>
> > IMHO, BV should specify a mechanism used by implementations to load<br>
> > resources and classes. The default implementation should work out of<br>
> > the box in Java EE and this mechanism can be customized by users<br>
> > which want to work in a modular environement.<br>
> ><br>
> ><br>
> > Maybe an implementation of such mechanism can be provided for OSGi<br>
> > or JBoss modules by the RI?<br>
> ><br>
> ><br>
> > WDYT?<br>
> ><br>
> ><br>
> > --Kevin<br>
> ><br>
> ><br>
> > On 31 oct. 2011, at 17:13, Gunnar Morling<br>
> > <<a href="mailto:gunnar.morling@googlemail.com">gunnar.morling@googlemail.com</a>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > > > So all JARs must be OSGi-ified before they can be used?<br>
> > > > [...]<br>
> > > > I'm asking because declaring dependencies means that all<br>
> > > > dependent JSRs (and<br>
> > > > the JDK) will need to be OSGi-ified as well. I'd rather<br>
> > > > see that coordinated<br>
> > > > by the Java EE expert group.<br>
> > ><br>
> > > In case of BV we would have to add the OSGi headers to the<br>
> > > JAR to make<br>
> > > it usable under OSGi. As Kevin says there is no relation<br>
> > > to the JDK<br>
> > > here, and AFAIK the BV API doesn't have any other<br>
> > > additional<br>
> > > dependencies. So adding these headers wouldn't be a<br>
> > > problem IMO (each<br>
> > > OSGi bundle is still a standard JAR which can be used in<br>
> > > any other<br>
> > > environment).<br>
> > ><br>
> > > Another thing is the bootstrapping, i.e. how BV<br>
> > > implementations are<br>
> > > found. Searching for resources such as<br>
> > > META-INF/services/j.v.ValidationProvider doesn't work in<br>
> > > OSGi (I don't<br>
> > > know about JBoss modules). This kind of things is in OSGi<br>
> > > typically<br>
> > > solved using services, that means in the BV bundle would<br>
> > > be the<br>
> > > definition of a service interface (we already have this<br>
> > > with<br>
> > > ValidationProvider) while BV providers would register<br>
> > > implementations<br>
> > > of this service. In the BV API Jar we still would need<br>
> > > some glue<br>
> > > code/meta-data to obtain references to these<br>
> > > implementations.<br>
> > ><br>
> > > Personally I feel adding the headers would be ok for the<br>
> > > "official"<br>
> > > API Jar as it's rather un-intrusive, but the bootstrapping<br>
> > > stuff might<br>
> > > be too much. One idea might be to provide separate<br>
> > > "enabler" modules<br>
> > > for the different module systems around, e.g. there could<br>
> > > be a<br>
> > > bv-osgi.jar which takes the raw API jar and makes it<br>
> > > usable under OSGi<br>
> > > (it could also offer j.v.Validator as OSGi service etc.).<br>
> > ><br>
> > > --Gunnar<br>
> > ><br>
> > > 2011/10/28 Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>>:<br>
> > > > So all JARs must be OSGi-ified before they can be used?<br>
> > > > Is there any way to<br>
> > > > keep this information outside? Do you know of any other<br>
> > > > JSR published JAR<br>
> > > > that also expose its OSGi headers?<br>
> > > > I'm asking because declaring dependencies means that all<br>
> > > > dependent JSRs (and<br>
> > > > the JDK) will need to be OSGi-ified as well. I'd rather<br>
> > > > see that coordinated<br>
> > > > by the Java EE expert group. There is also the problem<br>
> > > > of supporting them<br>
> > > > forever(tm).<br>
> > > > On 27 oct. 2011, at 22:52, Kevin Pollet wrote:<br>
> > > ><br>
> > > > Hi experts,<br>
> > > > IMHO, making Bean Validation ready for the modular world<br>
> > > > is a great thing!<br>
> > > > A first step might be to provide the module meta-datas<br>
> > > > (OSGi headers,<br>
> > > > …). For OSGi, those meta-datas can be added to the jar<br>
> > > > Manifest within the<br>
> > > > maven build with the maven-bundle-plugin. The advantage<br>
> > > > is that the api can<br>
> > > > be deployed in an OSGi container out of the box. For<br>
> > > > JBoss Modules the<br>
> > > > descriptor reside alongside its content but we can<br>
> > > > provide it.<br>
> > > > WDYT?<br>
> > > > --Kevin<br>
> > > ><br>
> > > > _______________________________________________<br>
> > > > beanvalidation-dev mailing list<br>
> > > > <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> > > > <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
> > > ><br>
> > > ><br>
> > > > _______________________________________________<br>
> > > > beanvalidation-dev mailing list<br>
> > > > <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> > > > <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
> > > ><br>
> > > ><br>
> > ><br>
> > > _______________________________________________<br>
> > > beanvalidation-dev mailing list<br>
> > > <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> > > <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
> > ><br>
> ><br>
> > _______________________________________________<br>
> > beanvalidation-dev mailing list<br>
> > <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > beanvalidation-dev mailing list<br>
> > <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
<br>
<br>
<br>
_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
</div></div></blockquote></div><br></div>