<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 8/21/2013 3:04 AM, Gunnar Morling
wrote:<br>
</div>
<blockquote
cite="mid:CADGJaX9TQAFayXkBK8tupSkMckAYEgfPtRqJC6MJgvbfJEercQ@mail.gmail.com"
type="cite">
<div dir="ltr">Hi Stan,
<div class="gmail_extra"><br>
<div class="gmail_quote">2013/8/20 <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:ssilvert@redhat.com"
target="_blank">ssilvert@redhat.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div class="im">
<div>On 8/14/2013 3:08 PM, Farah Juma wrote:<br>
</div>
<blockquote type="cite">
<pre>Hi,
I recently worked on CDI and Bean Validation integration for method validation (WFLY-529). As described in [1], part of this work involved replacing the delegate of the EE LazyValidatorFactory with a CDI-enabled ValidatorFactory. However, JCA and JPA still currently use copied versions of the old EE LazyValidatorFactory. Since JCA and JPA should also have access to the CDI-enabled ValidatorFactory, it would be good if we could remove the copies (i.e., remove JCAValidatorFactory and JPALazyValidatorFactory) and use the current EE LazyValidatorFactory directly instead. As discussed with Scott Marlow, for JPA, it looks like we can access the EE LazyValidatorFactory from the deployment unit attachment (i.e., via deploymentUnit.getAttachment(BeanValidationAttachments.VALIDATOR_FACTORY)), as described in WFLY-1705 [2]. However, for JCA, it doesn't seem like this will be possible since the code that currently instantiates the JCAValidatorFactory doesn't have access to the deploymen!
tUnit (and it seems like there isn't a way to modify the code to be able to access this). Another option might be to register the ValidatorFactory as a service and then perform a manual lookup on the service.
I was wondering if anyone had any thoughts about what approach to take for JCA or how to go about removing the JCAValidatorFactory. I've created WFLY-1882 [3] to track this. In addition to JCA and JPA, we'll need to consider what should be done for JSF since it will also need to be able to access the CDI-enabled ValidatorFactory. Note that JSF doesn't use a copy of the EE LazyValidatorFactory and so it seems to be bootstrapping Bean Validation in another way.</pre>
</blockquote>
</div>
Farah,<br>
<br>
JSF bootstraps Bean Validation as per JSF spec section <a
moz-do-not-send="true" href="http://3.5.6.2"
target="_blank">3.5.6.2</a>:<br>
<br>
<blockquote><i>The Bean Validation ValidatorFactory is
the main entry point into Bean Validation and is
responsible for creating</i><i><br>
</i><i>Validator instances.
[P1-start-validatoryfactory]A ValidatorFactory is
retrieved using the following algorithm:</i><i><br>
</i><i>If the servlet context contains a
ValidatorFactory instance under the attribute named</i><i><br>
</i><i>javax.faces.validator.beanValidator.ValidatorFactory,
this instance is used by JSF to acquire Validator
instances</i><i><br>
</i><i>(specifically in the BeanValidator). This key
should be defined in the constant named
VALIDATOR_FACTORY_KEY</i><i><br>
</i><i>on BeanValidator.</i><i><br>
</i><i>If the servlet context does not contain such an
entry, JSF looks for a Bean Validation provider in
the classpath. If</i><i><br>
</i><i>present, the standard Bean Validation bootstrap
strategy is used. If not present, Bean Validation
integration is</i><i><br>
</i><i>disabled.</i><i><br>
</i></blockquote>
In our case, we use the second method, which is to
simply place the Bean Validation provider in the
classpath. For every deployment that uses JSF, the JSF
subsystem will add the org.hibernate.validator module to
the deployment.
<div class="im"><br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Thanks for that info, that's very helpful. The problem
we're trying to solve is making sure that Bean Validation
and CDI are properly integrated as required by the BV
spec. For instance CDI-based dependency injection must be
available to constraint validator implementations.</div>
<div><br>
</div>
<div>The validator factory maintained in the WildFly EE
module (which e.g. is available via JNDI) provides this
functionality as it is configured as necessary during
bootstrap. A validator factory obtained via the standard
BV bootstrap strategy won't offer this functionality,
though.</div>
<div><br>
</div>
<div>So based on what you say, one solution for the JSF case
could be to make the VF from the EE module available in
the servlet context, e.g. by retrieving it via JNDI
(assuming the order of loading the modules allows for
that). I'm not sure though about a WAR deployment which is
CDI-enabled. Is the EE module activated in this case?</div>
</div>
</div>
</div>
</blockquote>
I'm not sure what you mean by "Is the EE module activated?".<br>
<br>
It's easy enough for you to try out putting your ValidatorFactory
into the ServletContext. This class is where bean validation is
added to the deployment and it also has an example of stuffing a
value into the ServletContext at deployment time.<br>
<a class="moz-txt-link-freetext" href="https://github.com/wildfly/wildfly/blob/master/jsf/subsystem/src/main/java/org/jboss/as/jsf/deployment/JSFDependencyProcessor.java">https://github.com/wildfly/wildfly/blob/master/jsf/subsystem/src/main/java/org/jboss/as/jsf/deployment/JSFDependencyProcessor.java</a><br>
<blockquote
cite="mid:CADGJaX9TQAFayXkBK8tupSkMckAYEgfPtRqJC6MJgvbfJEercQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div class="im"> <br>
<br>
<blockquote type="cite">
<pre>[1] <a moz-do-not-send="true" href="https://issues.jboss.org/browse/WFLY-529?focusedCommentId=12787076&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12787076" target="_blank">https://issues.jboss.org/browse/WFLY-529?focusedCommentId=12787076&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12787076</a>
[2] <a moz-do-not-send="true" href="https://issues.jboss.org/browse/WFLY-1705" target="_blank">https://issues.jboss.org/browse/WFLY-1705</a>
[3] <a moz-do-not-send="true" href="https://issues.jboss.org/browse/WFLY-1882" target="_blank">https://issues.jboss.org/browse/WFLY-1882</a>
Thanks,
Farah
_______________________________________________
wildfly-dev mailing list
<a moz-do-not-send="true" href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a>
</pre>
</blockquote>
<br>
</div>
</div>
<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/wildfly-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>