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 >
