August 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-5102) Upgrade Undertow to 2.1.4.Final

by Bartosz Spyrko-Smietanko (Jira)

[ https://issues.redhat.com/browse/WFCORE-5102?page=com.atlassian.jira.plug... ] Bartosz Spyrko-Smietanko updated WFCORE-5102: --------------------------------------------- Labels: downstream_dependency (was: ) > Upgrade Undertow to 2.1.4.Final > ------------------------------- > > Key: WFCORE-5102 > URL: https://issues.redhat.com/browse/WFCORE-5102 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Bartosz Spyrko-Smietanko > Assignee: Flavia Rainone > Priority: Blocker > Labels: downstream_dependency > > Upgrade Undertow to 2.1.3.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5102) Upgrade Undertow to 2.1.4.Final

by Bartosz Spyrko-Smietanko (Jira)

Bartosz Spyrko-Smietanko created WFCORE-5102: ------------------------------------------------ Summary: Upgrade Undertow to 2.1.4.Final Key: WFCORE-5102 URL: https://issues.redhat.com/browse/WFCORE-5102 Project: WildFly Core Issue Type: Component Upgrade Reporter: Bartosz Spyrko-Smietanko Assignee: Flavia Rainone Fix For: 12.0.1.Final Upgrade Undertow to 2.1.3.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-331) Bootable JAR - module.path system property affects tests execution

by Fabio Burzigotti (Jira)

Fabio Burzigotti created WFWIP-331: -------------------------------------- Summary: Bootable JAR - module.path system property affects tests execution Key: WFWIP-331 URL: https://issues.redhat.com/browse/WFWIP-331 Project: WildFly WIP Issue Type: Bug Reporter: Fabio Burzigotti Assignee: Jean Francois Denise WIP commit [1] demonstrates failures affecting tests execution for the `intergation/microprofile-tck/metrics` module. We're currently looking into those failures but we noticed that adding the `module.path` system property to the `surefire` plugin configuration would fix them [2]. That property should not be taken into account by the bootable JAR Maven plugin ant the modules in that path should not belong to the bootable JAR as well. [1] https://github.com/fabiobrz/wildfly/commit/727d96332fcb6e7ae851e6be6b1858... [2] https://github.com/fabiobrz/wildfly/pull/14/files#diff-89c7e61b9f8f99978b... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13515) Application does not fail when @Singleton @PostConstruct throws exception

by Bartosz Spyrko-Smietanko (Jira)

[ https://issues.redhat.com/browse/WFLY-13515?page=com.atlassian.jira.plugi... ] Bartosz Spyrko-Smietanko commented on WFLY-13515: ------------------------------------------------- [~brian.stansberry] https://github.com/wildfly/wildfly/pull/11711 should fixed this JIRA as well so I think this can be resolved. > Application does not fail when @Singleton @PostConstruct throws exception > ------------------------------------------------------------------------- > > Key: WFLY-13515 > URL: https://issues.redhat.com/browse/WFLY-13515 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 19.0.0.Final, 20.0.0.Beta1 > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > Labels: Regression, downstream_dependency > Attachments: helloWorld.ear > > > In EAP 6.4 , sub deployments were accessible before all Singleton's PostConstruct were finished, this was fixed via [1]. After this fix if an exception was thrown from PostConstruct, then the whole deployment was in a failed state as well. EAP 7.0 works the same as EAP 6.4 after the fix. > In EAP 7.3/7.2/7.1 when the Singleton throws an exception, the sub deployments are accessible. > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1310908 > EJB 3.1 spec, section 4.8.1: > {quote} > If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application. > {quote} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13515) Application does not fail when @Singleton @PostConstruct throws exception

by Bartosz Spyrko-Smietanko (Jira)

[ https://issues.redhat.com/browse/WFLY-13515?page=com.atlassian.jira.plugi... ] Bartosz Spyrko-Smietanko updated WFLY-13515: -------------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/11711 (was: https://github.com/wildfly/wildfly/pull/13325) > Application does not fail when @Singleton @PostConstruct throws exception > ------------------------------------------------------------------------- > > Key: WFLY-13515 > URL: https://issues.redhat.com/browse/WFLY-13515 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 19.0.0.Final, 20.0.0.Beta1 > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > Labels: Regression, downstream_dependency > Attachments: helloWorld.ear > > > In EAP 6.4 , sub deployments were accessible before all Singleton's PostConstruct were finished, this was fixed via [1]. After this fix if an exception was thrown from PostConstruct, then the whole deployment was in a failed state as well. EAP 7.0 works the same as EAP 6.4 after the fix. > In EAP 7.3/7.2/7.1 when the Singleton throws an exception, the sub deployments are accessible. > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1310908 > EJB 3.1 spec, section 4.8.1: > {quote} > If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application. > {quote} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13212) Boot messages related to activation of MP subsystems are inconsistent

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-13212?page=com.atlassian.jira.plugi... ] Bartosz Baranowski reassigned WFLY-13212: ----------------------------------------- Assignee: Bartosz Baranowski (was: Jeff Mesnil) > Boot messages related to activation of MP subsystems are inconsistent > --------------------------------------------------------------------- > > Key: WFLY-13212 > URL: https://issues.redhat.com/browse/WFLY-13212 > Project: WildFly > Issue Type: Bug > Components: MP Config, MP Fault Tolerance, MP JWT, MP OpenTracing > Affects Versions: 19.0.0.Beta3 > Reporter: Rostislav Svoboda > Assignee: Bartosz Baranowski > Priority: Major > > Boot messages related to activation of MP subsystems are inconsistent in package names and used wording. > - MP Config and MP JWT use {{_private}} package, the remaining do not. > - MP Config and MP JWT say {{Activating WildFly MicroProfile}}, the majority of specs says {{Activating Eclipse MicroProfile }} > - MP FT and MP OT say {{Activating MicroProfile}}, the majority of specs says {{Activating Eclipse MicroProfile }} > - MP FT "Activating ..." message ends {{subsystem.}} but should be in sync with others - {{Subsystem}} - no comma at the end, upper case for the first letter > Packages and "Activating ..." messages should sync. > {code} > 21:43:44,506 INFO [org.wildfly.extension.microprofile.config.smallrye._private] (ServerService Thread Pool -- 48) WFLYCONF0001: Activating WildFly MicroProfile Config Subsystem > 21:43:44,527 INFO [org.wildfly.extension.microprofile.jwt.smallrye._private] (ServerService Thread Pool -- 51) WFLYJWT0001: Activating WildFly MicroProfile JWT Subsystem > {code} > {code} > 21:43:44,523 INFO [org.wildfly.extension.microprofile.openapi.smallrye] (ServerService Thread Pool -- 53) WFLYMPOAI0001: Activating Eclipse MicroProfile OpenAPI Subsystem > 21:43:44,531 INFO [org.wildfly.extension.microprofile.health.smallrye] (ServerService Thread Pool -- 50) WFLYHEALTH0001: Activating Eclipse MicroProfile Health Subsystem > 21:43:44,533 INFO [org.wildfly.extension.microprofile.metrics.smallrye] (ServerService Thread Pool -- 52) WFLYMETRICS0001: Activating Eclipse MicroProfile Metrics Subsystem > 21:43:44,531 INFO [org.wildfly.extension.microprofile.faulttolerance] (ServerService Thread Pool -- 49) WFLYMPFTEXT0001: Activating MicroProfile Fault Tolerance subsystem. > {code} > CC [~brian.stansberry] / [~maeste] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13484) JSF - submitting empty fields does not work

by Chao Wang (Jira)

[ https://issues.redhat.com/browse/WFLY-13484?page=com.atlassian.jira.plugi... ] Chao Wang resolved WFLY-13484. ------------------------------ Resolution: Duplicate Issue > JSF - submitting empty fields does not work > ------------------------------------------- > > Key: WFLY-13484 > URL: https://issues.redhat.com/browse/WFLY-13484 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 19.1.0.Final > Reporter: Frank Heldt > Assignee: Chao Wang > Priority: Major > Fix For: 20.0.1.Final > > > A simple JSF webapp with an input field > <p:inputMask value="#\{myCtrl.num\}" mask="?9999" slotChar="" size="4" maxlength="4"/> > and in the controller > private Short num; // + getter/setter > When the input field is empty, the setter is never called on submit. > The same webapp under WildFly 19.0.0 works as expected, in this case the setter is called with a null value. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13484) JSF - submitting empty fields does not work

by Chao Wang (Jira)

[ https://issues.redhat.com/browse/WFLY-13484?page=com.atlassian.jira.plugi... ] Chao Wang updated WFLY-13484: ----------------------------- Fix Version/s: 20.0.1.Final > JSF - submitting empty fields does not work > ------------------------------------------- > > Key: WFLY-13484 > URL: https://issues.redhat.com/browse/WFLY-13484 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 19.1.0.Final > Reporter: Frank Heldt > Assignee: Chao Wang > Priority: Major > Fix For: 20.0.1.Final > > > A simple JSF webapp with an input field > <p:inputMask value="#\{myCtrl.num\}" mask="?9999" slotChar="" size="4" maxlength="4"/> > and in the controller > private Short num; // + getter/setter > When the input field is empty, the setter is never called on submit. > The same webapp under WildFly 19.0.0 works as expected, in this case the setter is called with a null value. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13484) JSF - submitting empty fields does not work

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-13484?page=com.atlassian.jira.plugi... ] Bartosz Baranowski reassigned WFLY-13484: ----------------------------------------- Assignee: Chao Wang (was: Farah Juma) > JSF - submitting empty fields does not work > ------------------------------------------- > > Key: WFLY-13484 > URL: https://issues.redhat.com/browse/WFLY-13484 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 19.1.0.Final > Reporter: Frank Heldt > Assignee: Chao Wang > Priority: Major > > A simple JSF webapp with an input field > <p:inputMask value="#\{myCtrl.num\}" mask="?9999" slotChar="" size="4" maxlength="4"/> > and in the controller > private Short num; // + getter/setter > When the input field is empty, the setter is never called on submit. > The same webapp under WildFly 19.0.0 works as expected, in this case the setter is called with a null value. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13498) @ApplicationScoped Bean Not Eagerly Instantiated on Wildfly 16

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-13498?page=com.atlassian.jira.plugi... ] Bartosz Baranowski commented on WFLY-13498: ------------------------------------------- In such case can you isolate it as reproducer? Retain deployment structure and just provide baremetal classes/sources? > @ApplicationScoped Bean Not Eagerly Instantiated on Wildfly 16 > -------------------------------------------------------------- > > Key: WFLY-13498 > URL: https://issues.redhat.com/browse/WFLY-13498 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 16.0.0.Final > Reporter: Fearghal O Maolcatha > Assignee: Matěj Novotný > Priority: Major > > I have an @ApplicationScoped bean that I want to be instantiated on application startup (see sample code below). I've registered for the servlet context initialization event but the init method is never invoked. The FactoryLocator is contained in a jar within my war's WEB-INF/lib directory. This same code was working on Wildfly 9 but no longer works after upgrading to Wildfly 16. > {code:java} > import javax.enterprise.context.ApplicationScoped; > import javax.enterprise.context.Initialized; > import javax.enterprise.event.Observes; > import javax.servlet.ServletContext; > @ApplicationScoped > public class FactoryLocator { > public FactoryLocator() { > System.out.println("In the constructor........................."); > } > private void init(@Observes @Initialized(ApplicationScoped.class) ServletContext sc) { > System.out.println("Invoking the event observer method.................."); > } > } > {code} > One workaround I discovered was to extract the contents of the jars in my war's WEB-INF/lib/ directory to my war's WEB-INF/classes directory. When I did this my FactorLocator bean was instantiated successfully. I'd prefer not to have to do this. > After debugging through the war's deployment, I noticed that the ServletContext is initialized before all the beans in the war's lib directory are processed (org.jboss.weld.bootstrap.BeanDeploymentModules:processBeanDeployments). The war's module is not aware of all observers until all the beans are processed. However, the ServletContextEvent is fired before all the observers are known. > Should this happen that ServletContext is created before all observers are known about? I've debugged one of the Wildfly QuickStart applications and the ServletContext isn't created until all bean deployments are processed and the code below is executed successfully. Is the order in which this happens supposed to be guaranteed? -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 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 August 2020