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 Christian Zambrano (Jira)

[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ] Christian Zambrano commented on WFLY-11956: ------------------------------------------- > The javadoc for @PostConstruct says, "The PostConstruct annotation is used on a method that needs to be executed after dependency injection is done to perform any initialization." It sounds like it's saying that in a properly defined class, all initialization would be completed after a call to a @PostConstruct annotated method, at which point it would be safe to do validation. If a class doesn't adhere to that, then it's out of our hands. Good point. Thanks for highlighting that. > @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)

7 years, 3 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: ------------------------------------- re: "t kind of makes sense to call this every time and within this method you figure whether you actually have some of those methods, or make it no-op otherwise. Cannot guarantee that other impls don't handle it differently though." Well, yes, [~christian.zambrano], but the CDI implementation could check if there is a @PostConstruct annotated method and, if not, skip calling postConstruct(). It seems safer to not assume that postConstruct() will be called. re: "whether all of the required calls can be done in a PostConstruct is hard to know" The javadoc for @PostConstruct says, "The PostConstruct annotation is used on a method that needs to be executed after dependency injection is done to perform any initialization." It sounds like it's saying that in a *properly defined* class, all initialization would be completed after a call to a @PostConstruct annotated method, at which point it would be safe to do validation. If a class doesn't adhere to that, then it's out of our hands. re: "I was simply trying to agree that if having a validation.xml with the contents you provided would have turned off this behavior that would have been the best answer for an app-developer to control this behavior. " Ah, good. I wish I understood why I'm not getting the behavior I expect. [~guillaume.smet], can you explain what I'm missing? > @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)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4440) Changes made via CLI in static-discovery are not reflected in host.xml

by Brian Stansberry (Jira)

Brian Stansberry created WFCORE-4440: ---------------------------------------- Summary: Changes made via CLI in static-discovery are not reflected in host.xml Key: WFCORE-4440 URL: https://issues.jboss.org/browse/WFCORE-4440 Project: WildFly Core Issue Type: Bug Components: Management Affects Versions: 9.0.0.Beta3, 8.0.0.Final Reporter: Brian Stansberry Assignee: Jeff Mesnil The value from this operation is not persisted in the host xml file, nor is it reflected in a read-resource response: /host=slave/core-service=discovery-options/static-discovery=primary:write-attribute(name=port,value=9999) It also doesn't put the HC in reload-required state. This works: /host=slave/core-service=discovery-options:write-attribute(name=options,value=[{static-discovery={name=primary,protocol="${jboss.domain.master.protocol:remote+http}",host="${jboss.domain.master.address}",port=9999}}] The /host=slave/core-service=discovery-options/static-discovery=* resources are meant to be a kind of alias for elements in that 'options' list to make it easier to manipulate the details. But that linkage has a bug. (Probably several.) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4441) Changes made via CLI in static-discovery are not reflected in host.xml

by Brian Stansberry (Jira)

Brian Stansberry created WFCORE-4441: ---------------------------------------- Summary: Changes made via CLI in static-discovery are not reflected in host.xml Key: WFCORE-4441 URL: https://issues.jboss.org/browse/WFCORE-4441 Project: WildFly Core Issue Type: Bug Components: Management Affects Versions: 8.0.0.Final, 9.0.0.Beta3 Reporter: Brian Stansberry Assignee: Jeff Mesnil The value from this operation is not persisted in the host xml file, nor is it reflected in a read-resource response: /host=slave/core-service=discovery-options/static-discovery=primary:write-attribute(name=port,value=9999) It also doesn't put the HC in reload-required state. This works: /host=slave/core-service=discovery-options:write-attribute(name=options,value=[{static-discovery={name=primary,protocol="${jboss.domain.master.protocol:remote+http}",host="${jboss.domain.master.address}",port=9999}}] The /host=slave/core-service=discovery-options/static-discovery=* resources are meant to be a kind of alias for elements in that 'options' list to make it easier to manipulate the details. But that linkage has a bug. (Probably several.) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3937) [DMN Editor] TextArea: Proposal to support <Ctrl>+<Enter> etc

by Michael Anstis (Jira)

Michael Anstis created DROOLS-3937: -------------------------------------- Summary: [DMN Editor] TextArea: Proposal to support <Ctrl>+<Enter> etc Key: DROOLS-3937 URL: https://issues.jboss.org/browse/DROOLS-3937 Project: Drools Issue Type: Enhancement Components: DMN Editor Affects Versions: 7.20.0.Final Reporter: Ivo Bek Assignee: Michael Anstis The {{TextArea}} used for {{LiteralExpression}} and {{DecisionTable}} columns (may be others) starts a new line when {{<Enter>}} is pressed. [~ibek] has requested that this is changed in the DMN Editor to commit/flush the value instead and {{<Ctrl>+<Enter>}} and {{<Alt>+<Enter>}} is used to start new lines within the {{TextArea}}. This would be consistent with _spreadsheets_. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3937) [DMN Editor] TextArea: Proposal to support <Ctrl>+<Enter> etc

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-3937?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-3937: ----------------------------------- Tester: Jozef Marko Labels: drools-tools (was: ) > [DMN Editor] TextArea: Proposal to support <Ctrl>+<Enter> etc > ------------------------------------------------------------- > > Key: DROOLS-3937 > URL: https://issues.jboss.org/browse/DROOLS-3937 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Affects Versions: 7.20.0.Final > Reporter: Ivo Bek > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > > The {{TextArea}} used for {{LiteralExpression}} and {{DecisionTable}} columns (may be others) starts a new line when {{<Enter>}} is pressed. [~ibek] has requested that this is changed in the DMN Editor to commit/flush the value instead and {{<Ctrl>+<Enter>}} and {{<Alt>+<Enter>}} is used to start new lines within the {{TextArea}}. This would be consistent with _spreadsheets_. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3888) rules in spreadsheet does not behave same way with drl.

by Kris Verlaenen (Jira)

[ https://issues.jboss.org/browse/DROOLS-3888?page=com.atlassian.jira.plugi... ] Kris Verlaenen updated DROOLS-3888: ----------------------------------- Component/s: eclipse plugin (was: build) (was: decision tables) > rules in spreadsheet does not behave same way with drl. > ------------------------------------------------------- > > Key: DROOLS-3888 > URL: https://issues.jboss.org/browse/DROOLS-3888 > Project: Drools > Issue Type: Bug > Components: eclipse plugin > Affects Versions: 7.18.0.Final > Reporter: Hiroko Miura > Assignee: Ant Stephenson > Priority: Major > Labels: support > > In 7.18.0.Final (RHDM7.3.0), the change introduced by [DROOLS-3523|https://issues.jboss.org/browse/DROOLS-3523] as stated in the following knowledge. > Rules don't fire after upgrading to RHDM 7.3.0 > https://access.redhat.com/solutions/4014541 > Therefore, DroolsTest.java in JBDS Drools sample project does not fire rules as expected. > However, DecisionTableTest.java still works even tough 'packages' attribute in kmodule.xml still specify folder instead of package, which is inconsistent behavior with DRL sample. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3888) rules in spreadsheet does not behave same way with drl.

by Kris Verlaenen (Jira)

[ https://issues.jboss.org/browse/DROOLS-3888?page=com.atlassian.jira.plugi... ] Kris Verlaenen reassigned DROOLS-3888: -------------------------------------- Assignee: Luca Molteni (was: Ant Stephenson) > rules in spreadsheet does not behave same way with drl. > ------------------------------------------------------- > > Key: DROOLS-3888 > URL: https://issues.jboss.org/browse/DROOLS-3888 > Project: Drools > Issue Type: Bug > Components: eclipse plugin > Affects Versions: 7.18.0.Final > Reporter: Hiroko Miura > Assignee: Luca Molteni > Priority: Major > Labels: support > > In 7.18.0.Final (RHDM7.3.0), the change introduced by [DROOLS-3523|https://issues.jboss.org/browse/DROOLS-3523] as stated in the following knowledge. > Rules don't fire after upgrading to RHDM 7.3.0 > https://access.redhat.com/solutions/4014541 > Therefore, DroolsTest.java in JBDS Drools sample project does not fire rules as expected. > However, DecisionTableTest.java still works even tough 'packages' attribute in kmodule.xml still specify folder instead of package, which is inconsistent behavior with DRL sample. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1793) Cache JsonProvider in JsonSecurityEventFormatter

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1793?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse reassigned ELY-1793: ------------------------------------- Assignee: Darran Lofthouse > Cache JsonProvider in JsonSecurityEventFormatter > ------------------------------------------------ > > Key: ELY-1793 > URL: https://issues.jboss.org/browse/ELY-1793 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Audit > Reporter: Philippe Marschall > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.9.0.CR4 > > > When profiling our application in production the overhead of repeatably looking up the JsonProvider in JsonSecurityEventFormatter became noticeable. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-723) Be ready for Day2 testing

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-723: ------------------------------------ Summary: Be ready for Day2 testing Key: SWSQE-723 URL: https://issues.jboss.org/browse/SWSQE-723 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan When Service Mesh GA will be happen, there is always a risk to have a Day2 testing of customer scenarios which failed on GA. Action Item: Have booked a baremetal servers (bladecenter, PSI, beaker... whatever) with OCP 4.1 installed. So when an issue happens on customer side, we can rapidly reproduce that and cooperate with dev on fixing. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2019