Menu
▾
▴
resteasy-developers
|
From: Abhijit S. <abh...@gm...> - 2014-02-11 06:13:37
|
Hi, I've a Groovy project where I use RESTEasy with CDI (Weld) and deploy to embedded Jetty. What I can't seem to get working is bean validation. The documentation says that adding 'resteasy-validator-provider-11' along with hibernate validator dependencies (hibernate-validator, hibernate-validator-cdi, javax.el-api, javax.el) is enough. But the bean validation is simply ignored by RESTEasy. I curiously also get the following message in the logs: plugins.validation.ValidatorContextResolver - Unable to find CDI supporting ValidatorFactory. Using default ValidatorFactory I tried registering Hibernate InjectingConstraintValidatorFactory in META-INF/validation.xml but it depends on a BeanManager being injected and blows up at runtime. What can I do to get this working? RESTEasy 3.0.6.Final Weld servlet 2.1.2.Final Hibernate validator 5.0.3.Final Jetty embedded 9.1.1.v20140108 Regards, Abhijit |
|
From: Abhijit S. <abh...@gm...> - 2014-02-12 00:22:27
|
Perhaps I didn't provide enough detail previously. The code can be found here https://github.com/abhijitsarkar/groovy/tree/master/movie-manager/movie-manager-web A log gist is here: https://gist.github.com/anonymous/8947319 I've tried everything under the sun without any success. Pls help. On Tue, Feb 11, 2014 at 1:13 AM, Abhijit Sarkar <abh...@gm...>wrote: > Hi, > I've a Groovy project where I use RESTEasy with CDI (Weld) and deploy to > embedded Jetty. What I can't seem to get working is bean validation. The > documentation says that adding 'resteasy-validator-provider-11' along with > hibernate validator dependencies (hibernate-validator, > hibernate-validator-cdi, javax.el-api, javax.el) is enough. But the bean > validation is simply ignored by RESTEasy. I curiously also get the > following message in the logs: > > plugins.validation.ValidatorContextResolver - Unable to find CDI > supporting ValidatorFactory. Using default ValidatorFactory > > I tried registering Hibernate InjectingConstraintValidatorFactory in > META-INF/validation.xml but it depends on a BeanManager being injected and > blows up at runtime. > > What can I do to get this working? > > RESTEasy 3.0.6.Final > Weld servlet 2.1.2.Final > Hibernate validator 5.0.3.Final > Jetty embedded 9.1.1.v20140108 > > Regards, > Abhijit > |
|
From: Bill B. <bb...@re...> - 2014-02-12 01:35:22
|
Not a combination we have tested or tried to get to work. Honestly, I
don't understand why you don't just use latest Wildfly/Arquillian as its
all integrated there. I can give you hints that may help to get it
together, but I don't have time to debug it for you.
#1. CDI integration is not being used in your resteasy deployment. add
the following context-param
<context-param>
<param-name>resteasy.injector.factory</param-name>
<param-value>org.jboss.resteasy.cdi.CdiInjectorFactory</para-value>
</context-param>
I'm not even sure that will work.
#2 The log message: "Unable to find CDI supporting ValidatorFactory"
means that Resteasy integration could not find a ValidatorFactory under
the InitialContext "java:comp/ValidatorFactory" Maybe CDI is not
enabled? I have never embedded Weld in a non JBoss environment.
On 2/11/2014 7:22 PM, Abhijit Sarkar wrote:
> Perhaps I didn't provide enough detail previously. The code can be found
> here
> https://github.com/abhijitsarkar/groovy/tree/master/movie-manager/movie-manager-web
>
> A log gist is here: https://gist.github.com/anonymous/8947319
>
> I've tried everything under the sun without any success. Pls help.
>
>
> On Tue, Feb 11, 2014 at 1:13 AM, Abhijit Sarkar
> <abh...@gm... <mailto:abh...@gm...>> wrote:
>
> Hi,
> I've a Groovy project where I use RESTEasy with CDI (Weld) and
> deploy to embedded Jetty. What I can't seem to get working is bean
> validation. The documentation says that adding
> 'resteasy-validator-provider-11' along with hibernate validator
> dependencies (hibernate-validator, hibernate-validator-cdi,
> javax.el-api, javax.el) is enough. But the bean validation is simply
> ignored by RESTEasy. I curiously also get the following message in
> the logs:
>
> plugins.validation.ValidatorContextResolver - Unable to find CDI
> supporting ValidatorFactory. Using default ValidatorFactory
>
> I tried registering Hibernate InjectingConstraintValidatorFactory in
> META-INF/validation.xml but it depends on a BeanManager being
> injected and blows up at runtime.
>
> What can I do to get this working?
>
> RESTEasy 3.0.6.Final
> Weld servlet 2.1.2.Final
> Hibernate validator 5.0.3.Final
> Jetty embedded 9.1.1.v20140108
>
> Regards,
> Abhijit
>
>
>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
From: Bill B. <bb...@re...> - 2014-02-12 02:29:54
|
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. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
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.
>
|
|
From: Ron S. <rs...@re...> - 2014-02-13 23:59:05
|
By the way, if you want to step through the code, Resteasy invokes
validation in org.jboss.resteasy.core.ResourceMethodInvoker and
org.jboss.resteasy.core.MethodInjectorImpl, both of which are in the
resteasy-jaxrs module.
Also, when I get the new validation/CDI stuff working, I'd like to
create a Jetty test. If you've figured out the problem by then, maybe
you can help me. ;-)
-Ron
On 02/13/2014 06:13 PM, Ron Sigal wrote:
> 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.
>>
>
>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
|
|
From: Ron S. <rs...@re...> - 2014-02-14 02:44:07
|
Hi Abhijit, I will add java:comp/env to the lookup code. I should have tested with some environment in addition to AS / WildFly. Thank you. -Ron On 02/13/2014 10:02 PM, Abhijit Sarkar wrote: > Ron, > You made a good point. The InjectingConstraintValidatorFactory does > use CDI itself for BeanManager injection, although I don't understand > why that'd be a problem. By the time it happens, the BeanManager > should've been bound to the JNDI. > > https://github.com/hibernate/hibernate-validator/blob/master/cdi/src/main/java/org/hibernate/validator/internal/cdi/InjectingConstraintValidatorFactory.java > > One thing I noticed is that the JNDI URL you're trying to look up is > only valid for an EE environment. Tomcat/Jetty doesn't allow an > application to bind to java:comp but only java:comp/env. You may wanna > retry the lookup with the later URL if the first one fails. Gosh, I > love Java EE but I think it's different specs have gotten out of hand > so much that they only work in a very restricted environment. > > Regards, > Abhijit > > > On Thu, Feb 13, 2014 at 5:13 PM, Ron Sigal <rs...@re... > <mailto:rs...@re...>> wrote: > > 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 <http://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. >> > > > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Resteasy-developers mailing list > Res...@li... > <mailto:Res...@li...> > https://lists.sourceforge.net/lists/listinfo/resteasy-developers > > |
|
From: Abhijit S. <abh...@gm...> - 2014-02-15 04:04:01
|
Last one bounced so sending again... On Fri, Feb 14, 2014 at 11:02 PM, Abhijit Sarkar <abh...@gm...>wrote: > I might've spoken too soon :) Now Weld is blowing up and I'm pretty sure, > this time it's not my mistake. https://issues.jboss.org/browse/WELD-1606 > I think more testing is required in the servlet containers. Let me know if > I can help in some way. > > Regards, > Abhijit > > > On Fri, Feb 14, 2014 at 4:18 PM, Ron Sigal <rs...@re...> wrote: > >> Hi Abhijit, >> >> That's great news. Resteasy is Bill Burke's project. You should start >> by assuming it works. ;-) >> >> re: "*When the validation fails though, there's no error message >> returned from the server* (at least not that I see as response to curl). >> Is it not set in the response?" >> >> Actually, an error report should come back. See >> http://docs.jboss.org/resteasy/docs/3.0.6.Final/userguide/html/Validation.html#d4e2429 >> . >> >> -Ron >> >> [Second attempt. Didn't find lists.sourceforge.ne] >> >> On 02/14/2014 09:28 AM, Abhijit Sarkar wrote: >> >> Ron, >> I found and fixed the problem, thanks to an eye opener from Michal Gajdos >> (http://blog.dejavu.sk), who asked if I was trying to validate the >> return value. >> >> I put the annotation on the method assuming it'd apply to everything in >> the method signature. What I actually wanted was to validate the parameter! >> When I moved the annotation from method to parameter, it worked! Here's >> the working code: >> https://github.com/abhijitsarkar/groovy/tree/resteasy/movie-manager >> >> Goes to show just how important it is to ask the right question. I >> spent days on it not realizing it was working all the time. >> >> Question for you: *When the validation fails though, there's no error >> message returned from the server* (at least not that I see as response >> to curl). Is it not set in the response? >> >> Thank you much. >> >> Regards, >> Abhijit >> >> >> On Thu, Feb 13, 2014 at 8:44 PM, Ron Sigal <rs...@re...> wrote: >> >>> Hi Abhijit, >>> >>> I will add java:comp/env to the lookup code. I should have tested with >>> some environment in addition to AS / WildFly. Thank you. >>> >>> -Ron >>> >>> On 02/13/2014 10:02 PM, Abhijit Sarkar wrote: >>> >>> Ron, >>> You made a good point. The InjectingConstraintValidatorFactory does use >>> CDI itself for BeanManager injection, although I don't understand why >>> that'd be a problem. By the time it happens, the BeanManager should've been >>> bound to the JNDI. >>> >>> >>> https://github.com/hibernate/hibernate-validator/blob/master/cdi/src/main/java/org/hibernate/validator/internal/cdi/InjectingConstraintValidatorFactory.java >>> >>> One thing I noticed is that the JNDI URL you're trying to look up is >>> only valid for an EE environment. Tomcat/Jetty doesn't allow an application >>> to bind to java:comp but only java:comp/env. You may wanna retry the lookup >>> with the later URL if the first one fails. Gosh, I love Java EE but I think >>> it's different specs have gotten out of hand so much that they only work in >>> a very restricted environment. >>> >>> Regards, >>> Abhijit >>> >>> >>> On Thu, Feb 13, 2014 at 5:13 PM, Ron Sigal <rs...@re...> wrote: >>> >>>> 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. >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Android apps run on BlackBerry 10 >>>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps. >>>> Now with support for Jelly Bean, Bluetooth, Mapview and more. >>>> Get your Android app in front of a whole new audience. Start now. >>>> >>>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Resteasy-developers mailing list >>>> Res...@li... >>>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers >>>> >>>> >>> >>> >> >> > |
Thanks for helping keep SourceForge clean.
X