short addition: in this case it's actually Application#getELResolver#getValue (brian confirmed it for Application#evaluateExpressionGet which is needed by extval as well)
regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2012/12/6 Gerhard Petracek <gerhard.petra...@gmail.com> > hi gerald, > > @ el issue with weld: > that sounds like a serious weld bug. > extval is just using the std. jsf-api (in this > case: javax.faces.application.Application#evaluateExpressionGet). > brian leathem confirmed the weld-issue -> maybe jozef can provide further > details. > > regards, > gerhard > > http://www.irian.at > > Your JSF/JavaEE powerhouse - > JavaEE Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > > > 2012/12/6 Gerhard Petracek <gerhard.petra...@gmail.com> > >> hi gerald, >> >> @ veto: >> ClassDeactivator is just for classes which are listed in config files of >> cdi, jsf,... (and the specs. don't provide a possibility to disable them). >> in your case you just need the std. ProcessAnnotatedType#veto provided by >> cdi itself. >> >> @ BeanValidation#modelValidation >> >> i wrote both (the annotation as well as the add-on) -> i'm happy if you >> can use one of both. >> however, please note that they work differently. >> the add-on triggers class-level validation (for special classes) at the >> end of the validation-phase of the request-lifecycle and >> BeanValidation#modelValidation is just the integration of class-level >> validation which gets triggered at the end of the update-model-values >> phase. >> >> @ snapshot repository: >> see [1] >> >> regards, >> gerhard >> >> [1] https://repository.apache.org/content/groups/snapshots >> >> http://www.irian.at >> >> Your JSF/JavaEE powerhouse - >> JavaEE Consulting, Development and >> Courses in English and German >> >> Professional Support for Apache MyFaces >> >> >> >> 2012/12/5 Gerald Turner <gtur...@unzane.com> >> >>> Hi Gerhard, thanks for the response! >>> >>> >>> Gerhard Petracek <gerhard.petra...@gmail.com> writes: >>> >>> > @codi + seam >>> > yes - that's possible. >>> > it depends on what you are using from both. >>> > e.g. in case of the jsf-module of codi + seam-faces you have to veto >>> > one of the producers for the FacesContext. >>> >>> Exactly, jsf/faces modules from both. Is vetoing done with >>> ClassDeactivator and writing a service-loader file? >>> >>> > @ "No CreationalContext registered for EL evaluation, it is likely >>> > that the the expression factory has not been wrapped by the CDI >>> > BeanManager, which must be done to use the ELResolver from CDI": >>> > >>> > ... sounds like an as7 issue. it occurs during the rendering process >>> > (see e.g. UIComponentBase#encodeBegin) -> as7 has to ensure that all >>> > parts of cdi and jsf are up and running. >>> >>> I spent some time digging around the issue going on a tip from JIRA >>> issue EXTVAL-140 (thanks Igor Guimaraes) - looks like it's a Weld bug. >>> Weld ELResolver#getValue implementation will fail unless it's nested in >>> a stack evaluating a Weld ValueExpression or MethodExpression. OTOH, >>> ValueExpression#getValue works every time. Even stranger is that when I >>> revert the project from CODI to Seam3, Weld ELResolver#getValue will >>> return nulls instead of throwing an exception. Attached is a dummy >>> RENDER_RESPONSE PhaseListener that exhibits the bug (all the >>> "tryELResolver" tests fail while all the "tryValueExpression" tests >>> succeed). I'll work on reporting this to Weld. Is there any chance a >>> work-around could be added to ExtVal 2.0.7-SNAPSHOT? (i.e. using a >>> ValueExpression instead of ELResolver for BV startup) >>> >>> > @enabling injection via @Advanced: >>> > the only known (and already fixed) issue is [1]. >>> >>> Is there a public maven repository where I can link 1.0.6-SNAPSHOT? >>> >>> > just fyi (since you wrote "JSR-303 cross-field validation"). >>> > annotations like @DateIs were introduced before the bv-spec. was >>> > released and don't use the bv-api at all (that's the reason why they >>> > are in a different validation module). >>> > you would need e.g. [2] to use the bv-api with a thin layer to allow >>> > bv based cross-field validation. >>> >>> I was wrong about my original statement that cross-field validation >>> wasn't working (whereas @DateIs was working)… they're both working. >>> >>> I had this question on the mailing list in March and you pointed me at >>> the extension then too. I didn't have to use the extension you wrote. >>> I'm using the following ExtVal-BV annotation on the fields of a CDI bean >>> that I want cross-validation: >>> @BeanValidation(modelValidation=@ModelValidation(isActive=true)) >>> …this has been working great - am I missing something? >>> >>> -- >>> Gerald Turner Email: gtur...@unzane.com JID: gtur...@unzane.com >>> GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5 >>> >> >> >
