[
https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin...
]
Ronald Sigal edited comment on WFLY-11956 at 4/26/19 4:54 PM:
--------------------------------------------------------------
[~gunnar.morling], I got a response from Santiago. I'm still digesting it.
\[Santiago's remarks are in red.\]
========================================
{color:#DE350B}Hi Ron,
See inline.
{color}
Hi Santiago,
I just created
https://github.com/eclipse-ee4j/jaxrs-api/issues/759.
As for the "if enabled", I had some confusion on that point, but then I thought
Guillaume Smet from the Hibernate Validator project clarified it. In particular, he said
that GreetingModel in
@GET
@Valid
@Produces(MediaType.APPLICATION_JSON)
GreetingModel getHelloGreeting() {...}
is getting validated during the property validation phase, rather than when
getHelloGretting() is called as a resource method.
{color:#DE350B}Right, so having a resource method that looks like a getter is bad idea to
begin with. Section 7.4 of the JAX-RS spec talks specifically about this case.{color}
To quote him, "When validating the bean in JaxrsInjectionTarget, you validate the
bean itself and thus all its properties - so all the fields and getters. It is not method
validation but property validation. That's why your configuration in the XML file is
useless. Getters are already not validated methods by default. But... they are validated
when you validate the properties of a bean", where, by "your configuration in
the XML file" he is referring to
<executable-validation>
<default-validated-executable-types>
<executable-type>CONSTRUCTORS</executable-type>
<executable-type>NON_GETTER_METHODS</executable-type>
</default-validated-executable-types>
</executable-validation>
So, the point is that there seems to be no mechanism for disabling getter validation
during the field/property validation phase. So "if enabled" doesn't seem to
be applicable. Does that make sense?
{color:#DE350B}Looks like there may have been some confusion here. We certainly heard at
the time “Getters are not validated by default” and that is what prompted the creation of
Section 7.4. I don’t believe we heard that they were validated in some other phase. If so,
there’s a clear disconnect in the JAX-RS spec.
It’s interesting because the JAX-RS spec was reviewed by validation experts at the time.
I must say, it would make more sense for getters to be validated. Perhaps the scope of
your issue needs to be broaden to cover this …
— Santiago{color}
On 4/26/19 2:05 PM, Santiago
Pericas-Geertsen wrote:
{color:#DE350B}>> Ron,
>
> I agree, the JAX-RS spec should mention @PostContruct as part of the validation
process. Do you want to file an issue?
>
> Incidentally, the “if enabled” is because getters are not validated by default as
described in Section 7.4 of the JAX-RS spec.
>
> — Santiago{color}
>
>> On Apr 26, 2019, at 12:03 PM, Ron Sigal <rsigal(a)redhat.com> wrote:
>>
>> The spirit of the validation process is that validation of fields/properties
should take place after injection and initialization has occurred. Given that further
initialization could take place in a @PostConstruct annotated method, shouldn't the
spec mention that?
>>
>> This question arose from discussion in
https://issues.jboss.org/browse/WFLY-11956
"@PostConstruct on @ApplicationScoped bean called too late in case @Valid is
annotated on a business method".
>>
>> -Ron
was (Author: ron_sigal):
[~gunnar.morling], I got a response from Santiago. I'm still digesting it:
========================================
Hi Ron,
See inline.
Hi Santiago,
I just created
https://github.com/eclipse-ee4j/jaxrs-api/issues/759.
As for the "if enabled", I had some confusion on that point, but then I thought
Guillaume Smet from the Hibernate Validator project clarified it. In particular, he said
that GreetingModel in
@GET
@Valid
@Produces(MediaType.APPLICATION_JSON)
GreetingModel getHelloGreeting() {...}
is getting validated during the property validation phase, rather than when
getHelloGretting() is called as a resource method.
Right, so having a resource method that looks like a getter is bad idea to begin with.
Section 7.4 of the JAX-RS spec talks specifically about this case.
To quote him, "When validating the bean in JaxrsInjectionTarget, you validate the
bean itself and thus all its properties - so all the fields and getters. It is not method
validation but property validation. That's why your configuration in the XML file is
useless. Getters are already not validated methods by default. But... they are validated
when you validate the properties of a bean", where, by "your configuration in
the XML file" he is referring to
<executable-validation>
<default-validated-executable-types>
<executable-type>CONSTRUCTORS</executable-type>
<executable-type>NON_GETTER_METHODS</executable-type>
</default-validated-executable-types>
</executable-validation>
So, the point is that there seems to be no mechanism for disabling getter validation
during the field/property validation phase. So "if enabled" doesn't seem to
be applicable. Does that make sense?
Looks like there may have been some confusion here. We certainly heard at the time
“Getters are not validated by default” and that is what prompted the creation of Section
7.4. I don’t believe we heard that they were validated in some other phase. If so, there’s
a clear disconnect in the JAX-RS spec.
It’s interesting because the JAX-RS spec was reviewed by validation experts at the time.
I must say, it would make more sense for getters to be validated. Perhaps the scope of
your issue needs to be broaden to cover this …
— Santiago
On 4/26/19 2:05 PM, Santiago
Pericas-Geertsen wrote:
>> Ron,
>>
>> I agree, the JAX-RS spec should mention @PostContruct as part of the validation
process. Do you want to file an issue?
>>
>> Incidentally, the “if enabled” is because getters are not validated by default
as described in Section 7.4 of the JAX-RS spec.
>>
>> — Santiago
>>
>>> On Apr 26, 2019, at 12:03 PM, Ron Sigal <rsigal(a)redhat.com> wrote:
>>>
>>> The spirit of the validation process is that validation of fields/properties
should take place after injection and initialization has occurred. Given that further
initialization could take place in a @PostConstruct annotated method, shouldn't the
spec mention that?
>>>
>>> This question arose from discussion in
https://issues.jboss.org/browse/WFLY-11956 "@PostConstruct on @ApplicationScoped bean
called too late in case @Valid is annotated on a business method".
>>>
>>> -Ron
@PostConstruct on @ApplicationScoped bean called too late in case
@Valid is annotated on a business method
----------------------------------------------------------------------------------------------------------
Key: WFLY-11956
URL:
https://issues.jboss.org/browse/WFLY-11956
Project: WildFly
Issue Type: Bug
Components: Bean Validation, REST
Affects Versions: 16.0.0.Final
Reporter: Joerg Baesner
Assignee: Ronald Sigal
Priority: Major
Attachments: logging.txt, playground.zip
Having a bean class with {{@ApplicationScoped}}, which has a {{@PostConstruct}} and is
implementing the following _Interface_:
{code}
@Path("/validated")
public interface ValidatedJaxRsInterface {
@GET
@Valid
@Produces(MediaType.APPLICATION_JSON)
GreetingModel getHelloGreeting();
}
{code}
will result in calling the {{getHelloGreeting}} method of the implementation class twice
*_before_* the {{@PostConstruct}} is getting executed.
This can be reproduced with the attached reproducer application...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)