[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
by Christian Zambrano (Jira)
[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ]
Christian Zambrano commented on WFLY-11956:
-------------------------------------------
What does "if enabled" mean in this case? I did read that and assumed that there was a part of the spec I didn't understand. Is this referring to the part of the bean validation spec about the executable validation options?
> @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)
5 years, 4 months
[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
by Christian Zambrano (Jira)
[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ]
Christian Zambrano commented on WFLY-11956:
-------------------------------------------
> The JAX-RS spec is silent on the question of postConstruct(), so ignoring it can't be considered a bug,
Agreed and happy to see that at least consideration is being given to improve the experience with the current implementation.
> @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)
5 years, 4 months
[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
by Ronald Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ]
Ronald Sigal commented on WFLY-11956:
-------------------------------------
Another question.
My understanding, based on [~guillaume.smet]'s clarification, is that
{code}
@Path("get")
@GET
@Valid
@Produces(MediaType.APPLICATION_JSON)
GreetingModel getHelloGreeting();
{code}
should lead to GreetingModel getting validated during the field/property validation phase, but a call like
{code}
client.target("http://localhost:8081/get").request().get()
{code}
should, by default, *not* result in validating GreetingModel.
Now, [~christian.zambrano] has pointed out that Phase 2 of the JAX-RS validation algorithm says, "Validate annotations on fields, property getters (if enabled) and the resource class." The parenthetical "if enabled" seems to contradict what I thought I understood. Hmmm.
> @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)
5 years, 4 months
[JBoss JIRA] (DROOLS-3944) DMN Editor: Data type usability study
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3944?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton reassigned DROOLS-3944:
-----------------------------------------
Assignee: Sarahjane Clark (was: Elizabeth Clayton)
> DMN Editor: Data type usability study
> -------------------------------------
>
> Key: DROOLS-3944
> URL: https://issues.jboss.org/browse/DROOLS-3944
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Environment: Version 7.4
> Reporter: Elizabeth Clayton
> Assignee: Sarahjane Clark
> Priority: Major
> Labels: UX, UXTeam, Usability, drools-tools
>
> Lightweight usability study to test the ease of use in viewing, creating, editing and deleting data types, particularly structured data types.
> GOALS: Access the Data Type editor in terms of productivity and usability.
> * Ease of use when creating a complex type (concern: minimizing the mouse usage.)
> * Ease of use when saving a basic data type (e.g. age: number)
> * Discoverability of actions in the kebab menu, especially, insert nested, delete.
> * Ease of use/accuracy: Type-ahead of the data type selector.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
by Ronald Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ]
Ronald Sigal edited comment on WFLY-11956 at 4/26/19 12:05 PM:
---------------------------------------------------------------
Thanks for clarifying, [~guillaume.smet]. At least I defensively claimed ignorance. ;-)
re: "Bean Validation really supposes that your objects are following the Java Beans specification."
I think that's one underlying point here. It's fair to assume that getters really are getters, in the Java Beans sense. [~christian.zambrano], sorry, but I think we may not have a happy ending here.
As for the issue with getters being executed twice, I note that Section 7.1 "Accessor methods" of the Javabeans spec (https://download.oracle.com/otn-pub/jcp/7224-javabeans-1.01-fr-spec-oth-J...) says, "So properties need not just be simple data fields, they can actually be computed values. Updates may have various programmatic side effects." I.e., getters aren't required to be idempotent, so calling them twice seems like a problem.
re: "Calling the PostConstruct before Phase 2 would still be in compliance with the spec and would better fit the sequence of events that are expected from CDI which is for the PostConstruct to be called after injections."
[~christian.zambrano], yes, I agree. The JAX-RS spec is silent on the question of postConstruct(), so ignoring it can't be considered a bug, but I agree that validating *after* calling the @PostConstruct method is more in line with the spirit of the algorithm. I've created RESTEASY-2227 "Validate fields/properties after calling @PostConstruct annotated method, if one exists" to get that done.
was (Author: ron_sigal):
Thanks for clarifying, [~guillaume.smet]. At least I defensively claimed ignorance. ;-)
re: "Bean Validation really supposes that your objects are following the Java Beans specification."
I think that's one underlying point here. It's fair to assume that getters really are getters, in the Java Beans sense. [~christian.zambrano], sorry, but I think we may not have a happy ending here.
As for the issue with getters being executed twice, I note that Section 7.1 "Accessor methods" of the Javabeans spec (https://download.oracle.com/otn-pub/jcp/7224-javabeans-1.01-fr-spec-oth-J...) says, "So properties need not just be simple data fields, they can actually be computed values. Updates
may have various programmatic side effects." I.e., getters aren't required to be idempotent, so calling them twice seems like a problem.
re: "Calling the PostConstruct before Phase 2 would still be in compliance with the spec and would better fit the sequence of events that are expected from CDI which is for the PostConstruct to be called after injections."
[~christian.zambrano], yes, I agree. The JAX-RS spec is silent on the question of postConstruct(), so ignoring it can't be considered a bug, but I agree that validating *after* calling the @PostConstruct method is more in line with the spirit of the algorithm. I've created RESTEASY-2227 "Validate fields/properties after calling @PostConstruct annotated method, if one exists" to get that done.
> @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)
5 years, 4 months
[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
by Ronald Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ]
Ronald Sigal commented on WFLY-11956:
-------------------------------------
I sent a question about @PostConstruct to the jax-rs mailing list (jaxrs-dev(a)eclipse.org). I think the issue should be mentioned in the spec.
> @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)
5 years, 4 months
[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
by Ronald Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ]
Ronald Sigal commented on WFLY-11956:
-------------------------------------
Thanks for clarifying, [~guillaume.smet]. At least I defensively claimed ignorance. ;-)
re: "Bean Validation really supposes that your objects are following the Java Beans specification."
I think that's one underlying point here. It's fair to assume that getters really are getters, in the Java Beans sense. [~christian.zambrano], sorry, but I think we may not have a happy ending here.
As for the issue with getters being executed twice, I note that Section 7.1 "Accessor methods" of the Javabeans spec (https://download.oracle.com/otn-pub/jcp/7224-javabeans-1.01-fr-spec-oth-J...) says, "So properties need not just be simple data fields, they can actually be computed values. Updates
may have various programmatic side effects." I.e., getters aren't required to be idempotent, so calling them twice seems like a problem.
re: "Calling the PostConstruct before Phase 2 would still be in compliance with the spec and would better fit the sequence of events that are expected from CDI which is for the PostConstruct to be called after injections."
[~christian.zambrano], yes, I agree. The JAX-RS spec is silent on the question of postConstruct(), so ignoring it can't be considered a bug, but I agree that validating *after* calling the @PostConstruct method is more in line with the spirit of the algorithm. I've created RESTEASY-2227 "Validate fields/properties after calling @PostConstruct annotated method, if one exists" to get that done.
> @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)
5 years, 4 months
[JBoss JIRA] (WFLY-12019) Cannot remove a undertow server resource at one time
by Bartosz Spyrko (Jira)
[ https://issues.jboss.org/browse/WFLY-12019?page=com.atlassian.jira.plugin... ]
Bartosz Spyrko moved JBEAP-16807 to WFLY-12019:
-----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-12019 (was: JBEAP-16807)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (Undertow)
(was: Web (Undertow))
Affects Version/s: 16.0.0.Final
(was: 7.0.0.CR1)
> Cannot remove a undertow server resource at one time
> ----------------------------------------------------
>
> Key: WFLY-12019
> URL: https://issues.jboss.org/browse/WFLY-12019
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 16.0.0.Final
> Reporter: Bartosz Spyrko
> Assignee: Bartosz Spyrko
> Priority: Major
>
> Cannot remove a server attribute.
> {noformat}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server:remove()
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service jboss.undertow.server.default-server.default-host was depended upon by service jboss.undertow.server.default-server.default-host.filter-ref.x-powered-by-header, service jboss.undertow.server.default-server.default-host.location.
> /, service jboss.undertow.server.default-server.default-host.filter-ref.server-header",
> "rolled-back" => true,
> "response-headers" => undefined
> }
> {noformat}
> However, it can be removed executing same command again.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
