<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Sorry for the long slack off.</div><div><br></div>OSGi is generally not my field but here are a few comments on what Gunnar and Kevin have said:<div><br></div><div>- we can definitely experiment with Hibernate Validator and offer some OOTB support for OSGi and other modularity solutions.</div><div>- 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</div><div>- we should align with what the CDI group does wrt OSGi headers especially since CDI will be an optional dependency of BV</div><div>- can someone flesh out a more concrete proposal and push it to <a href="http://beanvalidation.org/proposals/BVAL-251">http://beanvalidation.org/proposals/BVAL-251</a> ? Kevin do you want to take the lead?<br><div><br></div><div>Emmanuel</div><div><br><div><div>On 3 nov. 2011, at 12:13, Kevin Pollet wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi,<br><br><div class="gmail_quote">On 1 November 2011 15:36, Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF"><div>Two points. </div><div><br></div><div>CDI will be a dependency of Bean Validation (see topic on injection). </div><div><br></div><div>What does not work today in the following code in a modular environment?</div>
<div><br></div><div><pre style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;max-height:30em;overflow-x:auto;overflow-y:auto;word-wrap:normal">
<font face="Helvetica"><span style="white-space:normal">Validation </span></font></pre><pre style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;max-height:30em;overflow-x:auto;overflow-y:auto;word-wrap:normal">
<font face="Helvetica"><span style="white-space:normal"> .byDefaultProvider() </span></font></pre><pre style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;max-height:30em;overflow-x:auto;overflow-y:auto;word-wrap:normal">
<font face="Helvetica"><span style="white-space:normal"> .providerResolver( myOSGiResolver ) </span></font></pre><pre style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;max-height:30em;overflow-x:auto;overflow-y:auto;word-wrap:normal">
<font face="Helvetica"><span style="white-space:normal"> .configure()</span></font><font face="Helvetica"><span style="white-space:normal"> </span></font></pre><pre style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;max-height:30em;overflow-x:auto;overflow-y:auto;word-wrap:normal">
<font face="Helvetica"><span style="white-space:normal"> .buildValidatorFactory();</span></font><span style="font-family:arial;white-space:normal"> </span></pre></div></div></blockquote><div>
<br></div><div><div>The dependency to CDI will be optional, right? </div><div><br></div><div>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.</div>
<div><br></div><div>AFAIK, the following things doesn't work with that approach (not exhaustive):</div><div><br></div><div>* loading of validation and constraint mapping files</div><div>* loading of ValidationMessages.properties</div>
</div><div>* I've not tested it but I think the loading of the class specified in the xml files doesn't work</div><div><br></div><div>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).</div>
<div><br></div><div>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. </div>
<div><br></div><div>Maybe an implementation of such mechanism can be provided for OSGi or JBoss modules by the RI?</div><div><br></div><div>WDYT?</div><div><br></div><div>--Kevin</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF"><div><div><div>On 31 oct. 2011, at 17:13, Gunnar Morling <<a href="mailto:gunnar.morling@googlemail.com" target="_blank">gunnar.morling@googlemail.com</a>> wrote:<br><br></div></div>
</div><div><div><div></div><blockquote type="cite"><div><blockquote type="cite"><span>So all JARs must be OSGi-ified before they can be used? [...]</span><br></blockquote><blockquote type="cite"><span>I'm asking because declaring dependencies means that all dependent JSRs (and</span><br>
</blockquote><blockquote type="cite"><span>the JDK) will need to be OSGi-ified as well. I'd rather see that coordinated</span><br></blockquote><blockquote type="cite"><span>by the Java EE expert group.</span><br></blockquote>
<span></span><br><span>In case of BV we would have to add the OSGi headers to the JAR to make</span><br><span>it usable under OSGi. As Kevin says there is no relation to the JDK</span><br><span>here, and AFAIK the BV API doesn't have any other additional</span><br>
<span>dependencies. So adding these headers wouldn't be a problem IMO (each</span><br><span>OSGi bundle is still a standard JAR which can be used in any other</span><br><span>environment).</span><br><span></span><br>
<span>Another thing is the bootstrapping, i.e. how BV implementations are</span><br>
<span>found. Searching for resources such as</span><br><span>META-INF/services/j.v.ValidationProvider doesn't work in OSGi (I don't</span><br><span>know about JBoss modules). This kind of things is in OSGi typically</span><br>
<span>solved using services, that means in the BV bundle would be the</span><br><span>definition of a service interface (we already have this with</span><br><span>ValidationProvider) while BV providers would register implementations</span><br>
<span>of this service. In the BV API Jar we still would need some glue</span><br><span>code/meta-data to obtain references to these implementations.</span><br><span></span><br><span>Personally I feel adding the headers would be ok for the "official"</span><br>
<span>API Jar as it's rather un-intrusive, but the bootstrapping stuff might</span><br><span>be too much. One idea might be to provide separate "enabler" modules</span><br><span>for the different module systems around, e.g. there could be a</span><br>
<span>bv-osgi.jar which takes the raw API jar and makes it usable under OSGi</span><br><span>(it could also offer j.v.Validator as OSGi service etc.).</span><br><span></span><br><span>--Gunnar</span><br><span></span><br>
<span>2011/10/28 Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>>:</span><br>
<blockquote type="cite"><span>So all JARs must be OSGi-ified before they can be used? Is there any way to</span><br></blockquote><blockquote type="cite"><span>keep this information outside? Do you know of any other JSR published JAR</span><br>
</blockquote><blockquote type="cite"><span>that also expose its OSGi headers?</span><br></blockquote><blockquote type="cite"><span>I'm asking because declaring dependencies means that all dependent JSRs (and</span><br>
</blockquote><blockquote type="cite"><span>the JDK) will need to be OSGi-ified as well. I'd rather see that coordinated</span><br></blockquote><blockquote type="cite"><span>by the Java EE expert group. There is also the problem of supporting them</span><br>
</blockquote><blockquote type="cite"><span>forever(tm).</span><br></blockquote><blockquote type="cite"><span>On 27 oct. 2011, at 22:52, Kevin Pollet wrote:</span><br></blockquote><blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>Hi experts,</span><br></blockquote><blockquote type="cite"><span>IMHO, making Bean Validation ready for the modular world is a great thing!</span><br></blockquote><blockquote type="cite"><span>A first step might be to provide the module meta-datas (OSGi headers,</span><br>
</blockquote><blockquote type="cite"><span>…). For OSGi, those meta-datas can be added to the jar Manifest within the</span><br></blockquote><blockquote type="cite"><span>maven build with the maven-bundle-plugin. The advantage is that the api can</span><br>
</blockquote><blockquote type="cite"><span>be deployed in an OSGi container out of the box. For JBoss Modules the</span><br></blockquote><blockquote type="cite"><span>descriptor reside alongside its content but we can provide it.</span><br>
</blockquote><blockquote type="cite"><span>WDYT?</span><br></blockquote><blockquote type="cite"><span>--Kevin</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>_______________________________________________</span><br>
</blockquote><blockquote type="cite"><span>beanvalidation-dev mailing list</span><br></blockquote><blockquote type="cite"><span><a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a></span><br>
</blockquote><blockquote type="cite"><span><a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a></span><br></blockquote><blockquote type="cite">
<span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>_______________________________________________</span><br></blockquote><blockquote type="cite"><span>beanvalidation-dev mailing list</span><br>
</blockquote><blockquote type="cite"><span><a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a></span><br></blockquote><blockquote type="cite"><span><a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a></span><br>
</blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><span></span><br><span>_______________________________________________</span><br><span>beanvalidation-dev mailing list</span><br>
<span><a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a></span><br><span><a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a></span><br>
</div></blockquote></div></div></div><br>_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">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></blockquote></div><br>
_______________________________________________<br>beanvalidation-dev mailing list<br><a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/beanvalidation-dev<br></blockquote></div><br></div></div></body></html>