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 G
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.ir
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 bo
hi howard,
please ensure that you are using the current snapshot from [1].
if you still have issues, please provide a link to a simple demo.
(maybe you are facing an issue which affects codi but which isn't an issue
of codi itself.)
regards,
gerhard
[1] https://repository.apache.org/content/gro
I love and use forClass="...". Please take a look at [1] below, when you
get a chance to see all the chatter/discussion I had related to this topic.
Sometime after this topic, I tried 'again' to use @Advanced and still
didn't work. That is why I went with JSF @RequestScopedBeans that contain
'only
"Howard W. Smith, Jr." writes:
> I can confirm the same about CODI @Advanced not working in/with JSF
> @FacesConverter. My workaround (in a TomEE/CDI/MyFaces-CODI project)
> was to only add the @FacesConverter to JSF @RequestScoped managed
> beans, and they are working great in/with TomEE 1.5.1 S
Hi Gerhard, thanks for the response!
Gerhard Petracek 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 fro
hi gerald,
@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.
@ "No CreationalContext registered for EL evaluation, it is likely that the
the expression fac
I can confirm the same about CODI @Advanced not working in/with JSF
@FacesConverter. My workaround (in a TomEE/CDI/MyFaces-CODI project) was to
only add the @FacesConverter to JSF @RequestScoped managed beans, and they
are working great in/with TomEE 1.5.1 SNAPSHOT.
I have been told that CODI @Adv
Hello, I'm in the process of converting a JSF2/CDI application from
Seam3 to MyFaces ExtCDI/CODI. The application had been using MyFaces
ExtVal-BV so that JSR-303 cross-field validation would work in the
front-end. Simply replacing Seam3 with CODI evoked the following
stacktrace during the first
10 matches
Mail list logo
