Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Discussion" <users@myfaces.apache.org>
Received-SPF: pass (nike.apache.org: domain of gerhard.petracek@gmail.com
 designates 209.85.212.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAGJtJfGVbWCA9oMmRsO6b8e5ay8nPr7pgxynrV8GeuZjj4QfaA@mail.gmail.com>
References: 
 <CAGJtJfGVbWCA9oMmRsO6b8e5ay8nPr7pgxynrV8GeuZjj4QfaA@mail.gmail.com>
From: Gerhard Petracek <gerhard.petracek@gmail.com>
Date: Thu, 6 Dec 2012 01:33:04 +0100
Message-ID: 
 <CAGJtJfF60r5x+jOYXmV6WvW5LX6UPMyGtqnsnWR0gz+pi4+GWQ@mail.gmail.com>
Subject: Re: el issue with weld (was: Bug EXTVAL-130?)
To: MyFaces Discussion <users@myfaces.apache.org>
Cc: Jozef Hartinger <jharting@redhat.com>
Content-Type: multipart/alternative; boundary=bcaec54ee81238649104d0243f35

--bcaec54ee81238649104d0243f35
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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.petracek@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.petracek@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 b=
y
>> 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 <gturner@unzane.com>
>>
>>> Hi Gerhard, thanks for the response!
>>>
>>>
>>> Gerhard Petracek <gerhard.petracek@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)=85 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 bea=
n
>>> that I want cross-validation:
>>>   @BeanValidation(modelValidation=3D@ModelValidation(isActive=3Dtrue))
>>> =85this has been working great - am I missing something?
>>>
>>> --
>>> Gerald Turner   Email: gturner@unzane.com   JID: gturner@unzane.com
>>> GPG: 0xFA8CD6D5  21D9 B2E8 7FE7 F19E 5F7D  4D0C 3FA0 810F FA8C D6D5
>>>
>>
>>
>

--bcaec54ee81238649104d0243f35--