|
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 >>>> >>>> >>> >>> >> >> > |