|
From: Ron S. <rs...@re...> - 2014-02-13 23:12:56
|
Hi Abhijit,
As you've noted, the message
plugins.validation.ValidatorContextResolver - Unable to find CDI supporting ValidatorFactory. Using default ValidatorFactory
comes from ValidatorContextResolver in resteasy-validator-provider-11:
ValidatorFactory getValidatorFactory()
{
ValidatorFactory tmpValidatorFactory = validatorFactory;
if (tmpValidatorFactory == null)
{
synchronized (RD_LOCK)
{
tmpValidatorFactory = validatorFactory;
if (tmpValidatorFactory == null)
{
try
{
Context context = new InitialContext();
validatorFactory = tmpValidatorFactory =
ValidatorFactory.class.cast(context.lookup("java:comp/ValidatorFactory"));
logger.debug("Using CDI supporting " +
validatorFactory);
}
catch (NamingException e)
{
logger.info("Unable to find CDI supporting
ValidatorFactory. Using default ValidatorFactory");
HibernateValidatorConfiguration config =
Validation.byProvider(HibernateValidator.class).configure();
validatorFactory = tmpValidatorFactory =
config.buildValidatorFactory();
}
}
}
}
return validatorFactory;
}
Running in WildFly 8, the retrieved ValidatorFactory is
org.jboss.as.ee.beanvalidation.LazyValidatorFactory, which lives in
|jboss-as-ee-7.1.0.*final*.jar. I don't know exactly what
LazyValidatorFactory is, but I found the following in an old email:
|
> >>As of 1.1, Bean Validation integrates with CDI within EE
> environments (when the deployment is CDI-enabled), which e.g. allows
> to @Inject dependencies into validators.
> >>
> >>A VF bootstrapped via Validation#buildDefaultValidatorFactory() is
> not CDI-enabled, though. Therefore, in WF there will be a CDI portable
> extension provided by the HV project which registers a CDI-enabled
> ValidatorFactory for a deployment. The idea then is that any
> integrators of BV such as JAX-RS/RESTEasy use this VF.
> >
> >Does that exist now? How do we load that ValidatorFactory?
>
> There is LazyValidatorFactory in the WildFly EE module[1] which is
> added as attachment to the deployment unit (the key is
> BeanValidationAttachments.VALIDATOR_FACTORY) and also bound to JNDI
> (under "java:comp/ValidatorFactory").
>
It seems similar to the description of
InjectingConstraintValidatorFactory. Unless your constraint validators
themselves are using CDI injection, I'm not sure why falling back to the
default ValidatorFactory would prevent validation from occurring.
I see you've discovered RESTEASY-1008. I don't think it's the same
problem, since RESTEASY-1008 describes a situation in which validation
occurs, but enabling CDI causes problems. However, RESTEASY-1008 came
as a surprise, and the two problems could be related.
As a matter of fact, I'm working on RESTEASY-1008 and making some
progress. There are a lot of details to deal with, and I'm going to be
off next week, but as soon as I have some working jars I'll attach to
the discussion you recently joined at
https://community.jboss.org/message/854886#854886. Maybe they will
help. In the meantime, you could try to make sure either
LazyValidatorFactory or InjectingConstraintValidatorFactory is
available. That seems to be a Jetty issue, which I don't know much about.
-Ron
On 02/11/2014 10:29 PM, Bill Burke wrote:
>
> On 2/11/2014 9:02 PM, Abhijit Sarkar wrote:
>> Hi Bill,
>> 1. CDI itself is enabled (I get not null injections) and
>> CdiInjectorFactory is present in
>> jetty-override.xml,https://github.com/abhijitsarkar/groovy/blob/master/movie-manager/movie-manager-web/src/main/webapp/WEB-INF/jetty-override.xml.
>> 2. The log message is coming
>> from org.jboss.resteasy.plugins.validation.ValidatorContextResolver - I
>> found that much. What I'm trying to figure out is who's going to do this
>> binding in a non Java EE environment.
>>
> I don't know how this binding happens. Hopefully Ron knows...He did
> this integration.
>
|