June 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4670) Upgrade JBoss MSC to 1.4.12.Final

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4670?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4670: -------------------------------- Fix Version/s: 12.0.2.Final (was: 12.0.1.Final) > Upgrade JBoss MSC to 1.4.12.Final > --------------------------------- > > Key: WFCORE-4670 > URL: https://issues.redhat.com/browse/WFCORE-4670 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Server > Reporter: Katarina Hermanova > Assignee: Richard Opalka > Priority: Major > Fix For: 12.0.2.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4962) Add a SecurityMetaData for all deployments

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4962?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4962: -------------------------------- Fix Version/s: 12.0.2.Final (was: 12.0.1.Final) > Add a SecurityMetaData for all deployments > ------------------------------------------ > > Key: WFCORE-4962 > URL: https://issues.redhat.com/browse/WFCORE-4962 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 12.0.2.Final > > > For all deployments we should associate a new class SecurityMetaData with the deployment, initially the purpose of this will be to hold the ServiceName of any Elytron SecurityDomain if one is being used. > At a later point additional security policy information can be added as we move away from the ApplicationSecurityDomain resources. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4963) During Phase.CONFIGURE_MODULE populate SecurityMetaData with the name of any Virtual SecurityDomain

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4963?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4963: -------------------------------- Fix Version/s: 12.0.2.Final (was: 12.0.1.Final) > During Phase.CONFIGURE_MODULE populate SecurityMetaData with the name of any Virtual SecurityDomain > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-4963 > URL: https://issues.redhat.com/browse/WFCORE-4963 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 12.0.2.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4973) NPE due to timeout in LongOutputTestCase

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4973?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4973: -------------------------------- Fix Version/s: 12.0.2.Final (was: 12.0.1.Final) > NPE due to timeout in LongOutputTestCase > ---------------------------------------- > > Key: WFCORE-4973 > URL: https://issues.redhat.com/browse/WFCORE-4973 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Richard Opalka > Assignee: Richard Opalka > Priority: Major > Fix For: 12.0.2.Final > > > [ERROR] Tests run: 5, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 50.287 s <<< FAILURE! - in org.jboss.as.test.integration.management.cli.LongOutputTestCase > [ERROR] testDisabledOutputPagingViaXml(org.jboss.as.test.integration.management.cli.LongOutputTestCase) Time elapsed: 11.961 s <<< FAILURE! > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertNotNull(Assert.java:712) > at org.junit.Assert.assertNotNull(Assert.java:722) > at org.jboss.as.test.integration.management.cli.LongOutputTestCase.testDisabledOutputPaging(LongOutputTestCase.java:394) > at org.jboss.as.test.integration.management.cli.LongOutputTestCase.testDisabledOutputPagingViaXml(LongOutputTestCase.java:380) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.wildfly.core.testrunner.WildflyTestRunner.run(WildflyTestRunner.java:157) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75) > at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344) > at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417) > [ERROR] testDisabledOutputPagingViaArgument(org.jboss.as.test.integration.management.cli.LongOutputTestCase) Time elapsed: 11.849 s <<< FAILURE! > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertNotNull(Assert.java:712) > at org.junit.Assert.assertNotNull(Assert.java:722) > at org.jboss.as.test.integration.management.cli.LongOutputTestCase.testDisabledOutputPaging(LongOutputTestCase.java:394) > at org.jboss.as.test.integration.management.cli.LongOutputTestCase.testDisabledOutputPagingViaArgument(LongOutputTestCase.java:368) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.wildfly.core.testrunner.WildflyTestRunner.run(WildflyTestRunner.java:157) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75) > at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344) > at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13556) Memory leak in FlashScope - expired elements are not cleared

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13556?page=com.atlassian.jira.plugi... ] Brian Stansberry resolved WFLY-13556. ------------------------------------- Fix Version/s: 20.0.0.Final Resolution: Done > Memory leak in FlashScope - expired elements are not cleared > ------------------------------------------------------------ > > Key: WFLY-13556 > URL: https://issues.redhat.com/browse/WFLY-13556 > Project: WildFly > Issue Type: Bug > Components: JSF > Reporter: Farah Juma > Assignee: Bartosz Spyrko-Smietanko > Priority: Major > Fix For: 20.0.0.Final > > > Objects in FlashScope is not cleared and keep accumulating even if POST-REDIRECT-BACK is completed. > If we put a huge object to FlashScope continuously as the following code, Java heap space will be exhausted soon. > {code:java} > @Model > public class Action { > private static final int oneHundredMB = 1024 * 1024 * 100; > public String next() { > Flash flash = FacesContext.getCurrentInstance().getExternalContext().getFlash(); > flash.putNow("huge", new byte[oneHundredMB]); > return "index.xhtml?faces-redirect=true"; > } > } > {code} > When OutOfMemoryError is happened, flashInnerMap field in com.sun.faces.context.flash.ELFlash is bloated. > {noformat} > Class Name | Ref. Objects | Shallow Heap | Ref. Shallow Heap | Retained Heap > ----------------------------------------------------------------------------------------------------------------------------------------- > java.lang.Thread @ 0xeea24380 default task-1 Thread | 1 | 120 | 64 | 20,800 > '- <Java Local> com.sun.faces.context.flash.ELFlash @ 0xee9e4608 | 1 | 40 | 64 | 64 > '- flashInnerMap java.util.concurrent.ConcurrentHashMap @ 0xee9e4630| 1 | 64 | 64 | 314,574,048 > ----------------------------------------------------------------------------------------------------------------------------------------- > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13561) Upgrade jberet-core from 1.3.6.Final to 1.3.7.Final

by Cheng Fang (Jira)

Cheng Fang created WFLY-13561: --------------------------------- Summary: Upgrade jberet-core from 1.3.6.Final to 1.3.7.Final Key: WFLY-13561 URL: https://issues.redhat.com/browse/WFLY-13561 Project: WildFly Issue Type: Component Upgrade Components: Batch Reporter: Cheng Fang Assignee: Cheng Fang -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13542) Container does not enforce bean-managed concurrency for timeout methods

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13542?page=com.atlassian.jira.plugi... ] Cheng Fang resolved WFLY-13542. ------------------------------- Resolution: Explained Mark as resolved. Feel free to reopen it if you think there is more work to be done. > Container does not enforce bean-managed concurrency for timeout methods > ----------------------------------------------------------------------- > > Key: WFLY-13542 > URL: https://issues.redhat.com/browse/WFLY-13542 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 19.1.0.Final > Reporter: Fábio Silva > Assignee: Cheng Fang > Priority: Major > > Bean-managed concurrency for @Singleton EJBs is not enforced for timeout methods annotated with @Schedule. When a timeout is fired while the previous one is still running, the timeout method is not called. Instead, WildFly logs a warning like the following: > {code:java} > 20:58:54,000 WARN [org.jboss.as.ejb3.timer] (EJB default - 2) WFLYEJB0043: A previous execution of timer [id=aa716284-ef7b-4bb3-a356-a8ca187255c4 timedObjectId=myweb.myweb.MySingleton auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@303bd2d5 previousRun=Sun May 31 20:57:10 BRT 2020 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Sun May 31 20:58:54 BRT 2020 timerState=IN_TIMEOUT info=null] ScheduleExpression [second=0/1;minute=*;hour=*;dayOfMonth=*;month=*;dayOfWeek=*;year=*;timezoneID=null;start=null;end=null] is still in progress, skipping this overlapping scheduled execution at: Sun May 31 20:58:54 BRT 2020. > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5390) Fix intermittent failures in ClusteredMessagingTestCase

by Emmanuel Hugonnet (Jira)

[ https://issues.redhat.com/browse/WFLY-5390?page=com.atlassian.jira.plugin... ] Emmanuel Hugonnet reassigned WFLY-5390: --------------------------------------- Assignee: Emmanuel Hugonnet (was: Jeff Mesnil) > Fix intermittent failures in ClusteredMessagingTestCase > ------------------------------------------------------- > > Key: WFLY-5390 > URL: https://issues.redhat.com/browse/WFLY-5390 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: Emmanuel Hugonnet > Priority: Major > Labels: IntermittentFailure > > Test are ignored since https://github.com/wildfly/wildfly/pull/8174 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4995) Error popups when collection editor dialog is open

by Yeser Amer (Jira)

[ https://issues.redhat.com/browse/DROOLS-4995?page=com.atlassian.jira.plug... ] Yeser Amer updated DROOLS-4995: ------------------------------- Fix Version/s: 7.39.0.Final > Error popups when collection editor dialog is open > --------------------------------------------------- > > Key: DROOLS-4995 > URL: https://issues.redhat.com/browse/DROOLS-4995 > Project: Drools > Issue Type: Bug > Components: Test Scenarios Editor > Affects Versions: 7.32.0.Final > Reporter: Anna Dupliak > Assignee: Yeser Amer > Priority: Minor > Labels: drools-tools > Fix For: 7.39.0.Final > > Attachments: overlapError.webm > > > The error popup overlaps with collection dialog editor wlile navigating to the filing cell and releasing focus again (without clicking) > See the video -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4995) Error popups when collection editor dialog is open

by Yeser Amer (Jira)

[ https://issues.redhat.com/browse/DROOLS-4995?page=com.atlassian.jira.plug... ] Yeser Amer updated DROOLS-4995: ------------------------------- Story Points: 1 > Error popups when collection editor dialog is open > --------------------------------------------------- > > Key: DROOLS-4995 > URL: https://issues.redhat.com/browse/DROOLS-4995 > Project: Drools > Issue Type: Bug > Components: Test Scenarios Editor > Affects Versions: 7.32.0.Final > Reporter: Anna Dupliak > Assignee: Yeser Amer > Priority: Minor > Labels: drools-tools > Fix For: 7.39.0.Final > > Attachments: overlapError.webm > > > The error popup overlaps with collection dialog editor wlile navigating to the filing cell and releasing focus again (without clicking) > See the video -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 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 June 2020