April 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-1649: -------------------------------- Fix Version/s: 5.0.0.Alpha5 (was: 5.0.0.Alpha4) > RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1649 > URL: https://issues.jboss.org/browse/WFCORE-1649 > Project: WildFly Core > Issue Type: Bug > Components: Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > Labels: domain-mode > Fix For: 5.0.0.Alpha5 > > > The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems. > This is a big problem in the following scenarios: > 1) Mixed domain, where legacy slaves do not know about newly introduced classifications. > 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present. > A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But: > -- that doesn't help with problem 2) > -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3763) Upgrade JBoss MSC to 1.4.2.Final

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3763?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-3763: -------------------------------- Fix Version/s: 5.0.0.Alpha5 (was: 5.0.0.Alpha4) > Upgrade JBoss MSC to 1.4.2.Final > -------------------------------- > > Key: WFCORE-3763 > URL: https://issues.jboss.org/browse/WFCORE-3763 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Server > Reporter: Jeff Mesnil > Assignee: Richard Opalka > Fix For: 5.0.0.Alpha5 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3752) Add support for multi-value MSC services

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3752?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-3752: -------------------------------- Fix Version/s: 5.0.0.Alpha5 (was: 5.0.0.Alpha4) > Add support for multi-value MSC services > ---------------------------------------- > > Key: WFCORE-3752 > URL: https://issues.jboss.org/browse/WFCORE-3752 > Project: WildFly Core > Issue Type: Feature Request > Components: Server > Reporter: Richard Opalka > Assignee: Richard Opalka > Fix For: 5.0.0.Alpha5 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2261) NPE in FD_ALL2

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2261?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2261. ---------------------------- Resolution: Done This is caused by filter HAS_HEADER not checking for null messages. Null messages can happen when MessageBatch.remove(msg) is called. Fixed by adding a null check to the HAS_HEADER filter. > NPE in FD_ALL2 > -------------- > > Key: JGRP-2261 > URL: https://issues.jboss.org/browse/JGRP-2261 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.10 > Environment: WildFly 12.0.0.Final > Reporter: Rich DiCroce > Assignee: Bela Ban > Fix For: 4.0.12 > > > I'm seeing a NPE in FD_ALL2 from time to time. Not consistent but the reason isn't hard to see. Stack trace: > {code} > 16:08:06,244 ERROR [stderr] (thread-10,ee,RCD_GP (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null)) Exception in thread "thread-10,ee,RCD_GP (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null)" java.lang.NullPointerException > 16:08:06,244 ERROR [stderr] (thread-10,ee,RCD_GP (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null)) at org.jgroups.protocols.FD_ALL2.lambda$new$0(FD_ALL2.java:83) > 16:08:06,245 ERROR [stderr] (thread-10,ee,RCD_GP (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null)) at org.jgroups.util.MessageBatch.replaceIf(MessageBatch.java:220) > 16:08:06,245 ERROR [stderr] (thread-10,ee,RCD_GP (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null)) at org.jgroups.protocols.FD_ALL2.up(FD_ALL2.java:186) > 16:08:06,245 ERROR [stderr] (thread-10,ee,RCD_GP (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null)) at org.jgroups.stack.Protocol.up(Protocol.java:372) > 16:08:06,245 ERROR [stderr] (thread-10,ee,RCD_GP (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null)) at org.jgroups.stack.Protocol.up(Protocol.java:372) > 16:08:06,246 ERROR [stderr] (thread-10,ee,RCD_GP (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null)) at org.jgroups.stack.Protocol.up(Protocol.java:372) > 16:08:06,246 ERROR [stderr] (thread-10,ee,RCD_GP (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null)) at org.jgroups.protocols.TP.passBatchUp(TP.java:1274) > 16:08:06,246 ERROR [stderr] (thread-10,ee,RCD_GP (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null)) at org.jgroups.util.SubmitToThreadPool$BatchHandler.passBatchUp(SubmitToThreadPool.java:140) > 16:08:06,246 ERROR [stderr] (thread-10,ee,RCD_GP (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null)) at org.jgroups.util.SubmitToThreadPool$BatchHandler.run(SubmitToThreadPool.java:136) > 16:08:06,246 ERROR [stderr] (thread-10,ee,RCD_GP (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null)) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > 16:08:06,246 ERROR [stderr] (thread-10,ee,RCD_GP (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null)) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > 16:08:06,247 ERROR [stderr] (thread-10,ee,RCD_GP (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null)) at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > 16:08:06,247 ERROR [stderr] (thread-10,ee,RCD_GP (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null)) at java.lang.Thread.run(Thread.java:748) > {code} > HAS_HEADER is assuming msg is non-null, but MessageBatch makes it clear that it's valid for elements of the batch to be null, and replaceIf() doesn't perform a null check. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2262) "Frozen" coordinator causes the whole cluster to hang

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2262?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2262. ---------------------------- Resolution: Done FrozenCoordinatorTest was changed; another member C joins after B becomes the singleton cluster coordinator, this is successful. I only tested with FILE_PING but the logic is there anyway, and all subclasses (such as JDBC_PING) inherit it. Let me know if this works, and I can backport to changes to the 3.6 branch. > "Frozen" coordinator causes the whole cluster to hang > ----------------------------------------------------- > > Key: JGRP-2262 > URL: https://issues.jboss.org/browse/JGRP-2262 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.7 > Reporter: Pietro Paolini > Assignee: Bela Ban > Fix For: 4.0.12 > > Attachments: jdbc_test.xml, jgroup.zip > > > This is the result of an investigation I carried out for a problem we have experienced within our > application, the scenario it has been re-created by pausing the JVM using a debugger. > The discovery mechanism is JDBC_PING. > If the coordinator's JVM gets fronzen (for whatever reason) before the coordinator sets itself as the cluster coordinator and another node is started after that it will be unable to join the cluster and it will hang indefinitely. > This seems to be caused by the "continue" statement at > https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/... > I have prepared a simple application which can help in replicating the problem. > To replicate the problem : > 1) Make sure the JGROUPSPING is empty > 2) Run the application using an IDE and attaching a debugger to cause the JVM to > be paused at line Main.java:67, wait for it. > 3) Run the application in non debug mode or with gradle using "gradle run" and it will > hang indefinitely > Depending on the UUID/IP Address being used generated/assigned this may not happen all the time but it happened quite often in my local tests. > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10307) Upgrade HAL to 3.0.0.Beta1

by Harald Pehl (JIRA)

[ https://issues.jboss.org/browse/WFLY-10307?page=com.atlassian.jira.plugin... ] Harald Pehl updated WFLY-10307: ------------------------------- Description: Contains mainly bug fixes and some minor enhancements compared to HAL 3.0.0.Alpha3 > Upgrade HAL to 3.0.0.Beta1 > -------------------------- > > Key: WFLY-10307 > URL: https://issues.jboss.org/browse/WFLY-10307 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 13.0.0.Beta1 > > > Contains mainly bug fixes and some minor enhancements compared to HAL 3.0.0.Alpha3 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10307) Upgrade HAL to 3.0.0.Beta1

by Harald Pehl (JIRA)

[ https://issues.jboss.org/browse/WFLY-10307?page=com.atlassian.jira.plugin... ] Harald Pehl updated WFLY-10307: ------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/11129) > Upgrade HAL to 3.0.0.Beta1 > -------------------------- > > Key: WFLY-10307 > URL: https://issues.jboss.org/browse/WFLY-10307 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 13.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10307) Upgrade HAL to 3.0.0.Beta1

by Harald Pehl (JIRA)

Harald Pehl created WFLY-10307: ---------------------------------- Summary: Upgrade HAL to 3.0.0.Beta1 Key: WFLY-10307 URL: https://issues.jboss.org/browse/WFLY-10307 Project: WildFly Issue Type: Component Upgrade Components: Web Console Reporter: Harald Pehl Assignee: Harald Pehl Fix For: 13.0.0.Beta1 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2503) Do not use origin-repository.jboss.org, use repository.jboss.org instead in kie-parent pom

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2503?page=com.atlassian.jira.plugi... ] Geoffrey De Smet updated DROOLS-2503: ------------------------------------- Description: - repository.jboss.org is a load-balancing proxy for the jboss nexus. Nowadays it should offer much faster reads than the master one and barely slower writes (and we read far more than we write). - origin-repository.jboss.org is the actual nexus master instance, which we must not contact directly as a good citizen. Over 2 years ago, someone added a hack to workaround temporary stability issues with repository.jboss.org that made us go directly to origin-repository.jboss.org https://github.com/kiegroup/droolsjbpm-build-bootstrap/blob/master/pom.xm... That was never rolled back. Replace those 2 lines to use repository.jboss.org instead and remove the comment. Suggested actions:: - Replace those 2 lines to use repository.jboss.org instead and remove the comment - Look for the use of origin-repository.jboss.org in all repo's and change that too. -- the errai/uberfire/appformer parent pom might use it too - Delete your local .m2/repository and do a full downstream build. - Adjust any jenkins jobs (both blessed jobs and PR jobs) that have hard coded origin-repository.jboss.org somewhere was: - repository.jboss.org is a load-balancing proxy for the jboss nexus. Nowadays it should offer much faster reads than the master one and barely slower writes (and we read far more than we write). - origin-repository.jboss.org is the actual nexus master instance, which we must not contact directly as a good citizen. Over 2 years ago, someone added a hack to workaround temporary stability issues with repository.jboss.org that made us go directly to origin-repository.jboss.org https://github.com/kiegroup/droolsjbpm-build-bootstrap/blob/master/pom.xm... Replace those 2 lines to use repository.jboss.org instead and remove the comment Suggested actions:: - Replace those 2 lines to use repository.jboss.org instead and remove the comment - Look for the use of origin-repository.jboss.org in all repo's and change that too. -- the errai/uberfire/appformer parent pom might use it too - Delete your local .m2/repository and do a full downstream build. - Adjust any jenkins jobs (both blessed jobs and PR jobs) that have hard coded origin-repository.jboss.org somewhere > Do not use origin-repository.jboss.org, use repository.jboss.org instead in kie-parent pom > ------------------------------------------------------------------------------------------ > > Key: DROOLS-2503 > URL: https://issues.jboss.org/browse/DROOLS-2503 > Project: Drools > Issue Type: Task > Components: build > Reporter: Geoffrey De Smet > Assignee: Piotr Szubiakowski > Priority: Blocker > > - repository.jboss.org is a load-balancing proxy for the jboss nexus. Nowadays it should offer much faster reads than the master one and barely slower writes (and we read far more than we write). > - origin-repository.jboss.org is the actual nexus master instance, which we must not contact directly as a good citizen. > Over 2 years ago, someone added a hack to workaround temporary stability issues with repository.jboss.org that made us go directly to origin-repository.jboss.org > https://github.com/kiegroup/droolsjbpm-build-bootstrap/blob/master/pom.xm... > That was never rolled back. Replace those 2 lines to use repository.jboss.org instead and remove the comment. > Suggested actions:: > - Replace those 2 lines to use repository.jboss.org instead and remove the comment > - Look for the use of origin-repository.jboss.org in all repo's and change that too. > -- the errai/uberfire/appformer parent pom might use it too > - Delete your local .m2/repository and do a full downstream build. > - Adjust any jenkins jobs (both blessed jobs and PR jobs) that have hard coded origin-repository.jboss.org somewhere -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2503) Do not use origin-repository.jboss.org, use repository.jboss.org instead in kie-parent pom

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2503?page=com.atlassian.jira.plugi... ] Geoffrey De Smet reassigned DROOLS-2503: ---------------------------------------- Assignee: Piotr Szubiakowski (was: Ant Stephenson) > Do not use origin-repository.jboss.org, use repository.jboss.org instead in kie-parent pom > ------------------------------------------------------------------------------------------ > > Key: DROOLS-2503 > URL: https://issues.jboss.org/browse/DROOLS-2503 > Project: Drools > Issue Type: Task > Components: build > Reporter: Geoffrey De Smet > Assignee: Piotr Szubiakowski > Priority: Blocker > > - repository.jboss.org is a load-balancing proxy for the jboss nexus. Nowadays it should offer much faster reads than the master one and barely slower writes (and we read far more than we write). > - origin-repository.jboss.org is the actual nexus master instance, which we must not contact directly as a good citizen. > Over 2 years ago, someone added a hack to workaround temporary stability issues with repository.jboss.org that made us go directly to origin-repository.jboss.org > https://github.com/kiegroup/droolsjbpm-build-bootstrap/blob/master/pom.xm... > Replace those 2 lines to use repository.jboss.org instead and remove the comment > Suggested actions:: > - Replace those 2 lines to use repository.jboss.org instead and remove the comment > - Look for the use of origin-repository.jboss.org in all repo's and change that too. > -- the errai/uberfire/appformer parent pom might use it too > - Delete your local .m2/repository and do a full downstream build. > - Adjust any jenkins jobs (both blessed jobs and PR jobs) that have hard coded origin-repository.jboss.org somewhere -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 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 2018