April 2019 - jboss-jira - Jboss List Archives

[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)

6 years, 6 months

1
0
0 / 0

[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)

6 years, 6 months

1
0
0 / 0

[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)

6 years, 6 months

1
0
0 / 0

[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)

6 years, 6 months

1
0
0 / 0

[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 updated DROOLS-3944: -------------------------------------- Description: 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. was:Lightweight usability study to test the ease of use in viewing, creating, editing and deleting data types, particularly structured data types. > 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: Elizabeth Clayton > 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)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3944) DMN Editor: Data type usability study

by Elizabeth Clayton (Jira)

Elizabeth Clayton created DROOLS-3944: ----------------------------------------- Summary: 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: Elizabeth Clayton Lightweight usability study to test the ease of use in viewing, creating, editing and deleting data types, particularly structured data types. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3942) DMN Fix wrong snippet for XML/JAXB request/response Traffic Violation

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-3942: -------------------------------------- Summary: DMN Fix wrong snippet for XML/JAXB request/response Traffic Violation Key: DROOLS-3942 URL: https://issues.jboss.org/browse/DROOLS-3942 Project: Drools Issue Type: Bug Components: docs Reporter: Matteo Mortari Assignee: Matteo Mortari -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3943) DMN Fix wrong snippet for XML/JAXB request/response Traffic Violation

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-3943: -------------------------------------- Summary: DMN Fix wrong snippet for XML/JAXB request/response Traffic Violation Key: DROOLS-3943 URL: https://issues.jboss.org/browse/DROOLS-3943 Project: Drools Issue Type: Bug Components: docs Reporter: Matteo Mortari Assignee: Matteo Mortari -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4434) Upgrade slf4j to 1.7.26

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/WFCORE-4434?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFCORE-4434: ---------------------------------- Summary: Upgrade slf4j to 1.7.26 (was: Upgrade slf4j to 1.7.25) > Upgrade slf4j to 1.7.26 > ----------------------- > > Key: WFCORE-4434 > URL: https://issues.jboss.org/browse/WFCORE-4434 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Build System > Reporter: Ilia Vassilev > Assignee: James Perkins > Priority: Major > Labels: downstream_dependency > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4447) Elytron: Ability to load the attributes of an identity from multiple sources

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-4447?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved EAP7-1246 to WFCORE-4447: ------------------------------------------------ Project: WildFly Core (was: EAP 7 Planning Pilot) Key: WFCORE-4447 (was: EAP7-1246) Issue Type: Feature Request (was: Requirement) Workflow: GIT Pull Request workflow (was: EAP Agile Workflow 2.0) Component/s: Security (was: Security) EAP PT Pre-Checked (PC): (was: TODO) Target Release: (was: 7.3.0.GA) EAP PT Community Docs (CD): (was: TODO) EAP PT Product Docs (PD): (was: New) EAP PT Test Dev (TD): (was: TODO) EAP PT Docs Analysis (DA): (was: TODO) EAP PT Test Plan (TP): (was: TODO) EAP PT Analysis Document (AD): (was: TODO) Writer: (was: Chuck Copello) > Elytron: Ability to load the attributes of an identity from multiple sources > ---------------------------------------------------------------------------- > > Key: WFCORE-4447 > URL: https://issues.jboss.org/browse/WFCORE-4447 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 9.0.0.Beta4 > > > In previous versions a {{security-domain}} was used to merge or add roles from multiple repositories. For example the roles for the users were obtained from two different ldaps and a database. All the roles were merged and the final authenticated principal belonged to all of them. The old picketbox subsystem used stacking of login modules (and password) to implement this feature. This use-case is not rare among the customers. > This issue is avoiding migrations from the old security subsystem to elytron. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2019