April 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1796) Release WildFly Elytron 2.0.0.Alpha4

by Darran Lofthouse (Jira)

Darran Lofthouse created ELY-1796: ------------------------------------- Summary: Release WildFly Elytron 2.0.0.Alpha4 Key: ELY-1796 URL: https://issues.jboss.org/browse/ELY-1796 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 2.0.0.Alpha4 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 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 Gunnar Morling (Jira)

[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ] Gunnar Morling edited comment on WFLY-11956 at 4/25/19 12:20 PM: ----------------------------------------------------------------- Hi, AFAICS, this is a case of (mostly) "works as designed": JAX-RS mandates the validation of properties on the resource class (see the validation routine in 7.6 of the [JAX-RS 2.0. spec|https://download.oracle.com/otn-pub/jcp/jaxrs-2_0-fr-eval-spec/jsr33...], phase 2 ("Validate annotations on fields, property getters (if enabled) and the resource class."). So a resource method that follows the bean property naming semantics would be validated here. Note I say "mostly", is this should only explain *one* invocation, but not two. As [~guillaume.smet] points out, suppressing this validation will not be trivial, as in all likelyhood one still would want to validate any other getters which are not also resource endpoints to be validated in that phase 2. The immediate work-around would be indeed to avoid naming resource endpoint methods as getters. In addition we might explore providing more fine-grained control over the properties to validate during phase 2. Essentially, it'd require some sort of filtering SPI provided by HV and implemented by RESTEasy which gives the latter the control to exclude specific properties from validation. But I'd consider this more as feature request for future versions than as a bug fix (again apart from the fact that the method seems to be invoked twice before post-construct). was (Author: gunnar.morling): Hi, AFAICS, this is a case of (mostly) "works as designed": JAX-RS mandates the validation of properties on the resource class (see the validation routine in 7.6 of the JAX-RS spec, phase 2 ("Validate annotations on fields, property getters (if enabled) and the resource class."). So a resource method that follows the bean property naming semantics would be validated here. Note I say "mostly", is this should only explain *one* invocation, but not two. As [~guillaume.smet] points out, suppressing this validation will not be trivial, as in all likelyhood one still would want to validate any other getters which are not also resource endpoints to be validated in that phase 2. The immediate work-around would be indeed to avoid naming resource endpoint methods as getters. In addition we might explore providing more fine-grained control over the properties to validate during phase 2. Essentially, it'd require some sort of filtering SPI provided by HV and implemented by RESTEasy which gives the latter the control to exclude specific properties from validation. But I'd consider this more as feature request for future versions than as a bug fix (again apart from the fact that the method seems to be invoked twice before post-construct). > @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, 5 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 Gunnar Morling (Jira)

[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ] Gunnar Morling reassigned WFLY-11956: ------------------------------------- Assignee: Ronald Sigal (was: Gunnar Morling) > @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, 5 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 Gunnar Morling (Jira)

[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ] Gunnar Morling commented on WFLY-11956: --------------------------------------- Hi, AFAICS, this is a case of (mostly) "works as designed": JAX-RS mandates the validation of properties on the resource class (see the validation routine in 7.6 of the JAX-RS spec, phase 2 ("Validate annotations on fields, property getters (if enabled) and the resource class."). So a resource method that follows the bean property naming semantics would be validated here. Note I say "mostly", is this should only explain *one* invocation, but not two. As [~guillaume.smet] points out, suppressing this validation will not be trivial, as in all likelyhood one still would want to validate any other getters which are not also resource endpoints to be validated in that phase 2. The immediate work-around would be indeed to avoid naming resource endpoint methods as getters. In addition we might explore providing more fine-grained control over the properties to validate during phase 2. Essentially, it'd require some sort of filtering SPI provided by HV and implemented by RESTEasy which gives the latter the control to exclude specific properties from validation. But I'd consider this more as feature request for future versions than as a bug fix (again apart from the fact that the method seems to be invoked twice before post-construct). > @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: Gunnar Morling > 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, 5 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 Gunnar Morling (Jira)

[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ] Gunnar Morling reassigned WFLY-11956: ------------------------------------- Assignee: Gunnar Morling (was: Ronald Sigal) > @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: Gunnar Morling > 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, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3940) DMN Editor: Update contextual menus (headers and cells.)

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-3940?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-3940: ----------------------------------- Attachment: (was: Screen Shot 2019-04-18 at 5.04.49 PM.png) > DMN Editor: Update contextual menus (headers and cells.) > -------------------------------------------------------- > > Key: DROOLS-3940 > URL: https://issues.jboss.org/browse/DROOLS-3940 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Michael Anstis > Priority: Major > Labels: Field, UX, UXTeam, drools-tools > Attachments: header-context2b.png > > > As a user of this feature I want to have the possibility to add columns or rows in a DT when right-clicking on the table header. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3940) DMN Editor: Update contextual menus (headers and cells.)

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-3940?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-3940: ----------------------------------- Attachment: (was: header-context.png) > DMN Editor: Update contextual menus (headers and cells.) > -------------------------------------------------------- > > Key: DROOLS-3940 > URL: https://issues.jboss.org/browse/DROOLS-3940 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Michael Anstis > Priority: Major > Labels: Field, UX, UXTeam, drools-tools > Attachments: header-context2b.png > > > As a user of this feature I want to have the possibility to add columns or rows in a DT when right-clicking on the table header. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3892) [DMN Designer] Data Types tab - Add a nested row to a new Structured data type by default

by Elizabeth Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-3892?page=com.atlassian.jira.plugi... ] Elizabeth Clayton updated DROOLS-3892: -------------------------------------- Labels: FieldEnablementFeedback UX UXTeam drools-tools (was: UX UXTeam drools-tools) > [DMN Designer] Data Types tab - Add a nested row to a new Structured data type by default > ----------------------------------------------------------------------------------------- > > Key: DROOLS-3892 > URL: https://issues.jboss.org/browse/DROOLS-3892 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Guilherme Gomes > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: Screen Shot 2019-04-03 at 4.15.11 PM.png > > > Usability enhancement request: Reduce the number of clicks / actions to add a nested element. > Solution description: > When the user creates a data type, of the type "Structured" a child row will get added to the list automatically. The child row will be in Edit mode by default. Design demo to illustrate. https://redhat.invisionapp.com/share/FERHG55ZAPH -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3892) [DMN Designer] Data Types tab - Add a nested row to a new Structured data type by default

by Elizabeth Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-3892?page=com.atlassian.jira.plugi... ] Elizabeth Clayton updated DROOLS-3892: -------------------------------------- Labels: UX UXTeam drools-tools (was: FieldEnablementFeedback UX UXTeam drools-tools) > [DMN Designer] Data Types tab - Add a nested row to a new Structured data type by default > ----------------------------------------------------------------------------------------- > > Key: DROOLS-3892 > URL: https://issues.jboss.org/browse/DROOLS-3892 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Guilherme Gomes > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: Screen Shot 2019-04-03 at 4.15.11 PM.png > > > Usability enhancement request: Reduce the number of clicks / actions to add a nested element. > Solution description: > When the user creates a data type, of the type "Structured" a child row will get added to the list automatically. The child row will be in Edit mode by default. Design demo to illustrate. https://redhat.invisionapp.com/share/FERHG55ZAPH -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3892) [DMN Designer] Data Types tab - Add a nested row to a new Structured data type by default

by Elizabeth Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-3892?page=com.atlassian.jira.plugi... ] Elizabeth Clayton updated DROOLS-3892: -------------------------------------- Labels: UX UXTeam drools-tools (was: drools-tools) > [DMN Designer] Data Types tab - Add a nested row to a new Structured data type by default > ----------------------------------------------------------------------------------------- > > Key: DROOLS-3892 > URL: https://issues.jboss.org/browse/DROOLS-3892 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Guilherme Gomes > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: Screen Shot 2019-04-03 at 4.15.11 PM.png > > > Usability enhancement request: Reduce the number of clicks / actions to add a nested element. > Solution description: > When the user creates a data type, of the type "Structured" a child row will get added to the list automatically. The child row will be in Edit mode by default. Design demo to illustrate. https://redhat.invisionapp.com/share/FERHG55ZAPH -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2019