January 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2723) Accessing "serverInventory" without holding lock "serverInventoryLock"

by Rostislav Svoboda (JIRA)

Rostislav Svoboda created WFLY-2723: --------------------------------------- Summary: Accessing "serverInventory" without holding lock "serverInventoryLock" Key: WFLY-2723 URL: https://issues.jboss.org/browse/WFLY-2723 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Domain Management Reporter: Rostislav Svoboda Assignee: Emanuel Muckenhuber Accessing "serverInventory" without holding lock "org.jboss.as.host.controller.DomainModelControllerService.serverInventoryLock". Elsewhere, "serverInventory" is accessed with "DomainModelControllerService.serverInventoryLock" held 4 out of 5 times. https://github.com/wildfly/wildfly/blob/master/host-controller/src/main/j... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2696) management audit settings: syslog protocol is lowercase while uppercase is expected

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2696?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2696: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1047519, https://bugzilla.redhat.com/show_bug.cgi?id=1047536, https://bugzilla.redhat.com/show_bug.cgi?id=1049824 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1047519, https://bugzilla.redhat.com/show_bug.cgi?id=1047536) > management audit settings: syslog protocol is lowercase while uppercase is expected > ----------------------------------------------------------------------------------- > > Key: WFLY-2696 > URL: https://issues.jboss.org/browse/WFLY-2696 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.CR1 > Environment: - 8.0.0 CR1 + latest code in master > - domain mode > Reporter: Tom Fonteyne > Assignee: Tom Fonteyne > > Add a syslog handler to the audit settings of the management service of the domain controller, then start an instance. It fails to start with: > JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.IllegalArgumentException: No enum const class org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.udp > at java.lang.Enum.valueOf(Enum.java:214) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2721) Make the add-user password "requirements" prompt match the password.restriction setting

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2721?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-2721: ----------------------------------- Fix Version/s: 8.0.0.Final > Make the add-user password "requirements" prompt match the password.restriction setting > --------------------------------------------------------------------------------------- > > Key: WFLY-2721 > URL: https://issues.jboss.org/browse/WFLY-2721 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Domain Management, Security > Affects Versions: 8.0.0.CR1 > Reporter: Brian Stansberry > Assignee: Darran Lofthouse > Fix For: 8.0.0.Final > > > When you use add-user.sh it gives you a message re password "requirements" > Password requirements are listed below. To modify these restrictions edit the add-user.properties configuration file. > ... > But then, if add-user.properties has password.restriction=WARN (the default) the requirements are not enforced: > Password : > JBAS015269: Password must have at least 8 characters! > Are you sure you want to use the password entered yes/no? yes > This is a bit confusing. Better would be to tailor the initial prompt to the password.restriction setting. For example for WARN (and perhaps RELAX): > Password recommendations are listed below. To modify these recommendations edit the add-user.properties configuration file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2721) Make the add-user password "requirements" prompt match the password.restriction setting

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2721?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-2721: -------------------------------------- Assignee: Darran Lofthouse > Make the add-user password "requirements" prompt match the password.restriction setting > --------------------------------------------------------------------------------------- > > Key: WFLY-2721 > URL: https://issues.jboss.org/browse/WFLY-2721 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Domain Management, Security > Affects Versions: 8.0.0.CR1 > Reporter: Brian Stansberry > Assignee: Darran Lofthouse > > When you use add-user.sh it gives you a message re password "requirements" > Password requirements are listed below. To modify these restrictions edit the add-user.properties configuration file. > ... > But then, if add-user.properties has password.restriction=WARN (the default) the requirements are not enforced: > Password : > JBAS015269: Password must have at least 8 characters! > Are you sure you want to use the password entered yes/no? yes > This is a bit confusing. Better would be to tailor the initial prompt to the password.restriction setting. For example for WARN (and perhaps RELAX): > Password recommendations are listed below. To modify these recommendations edit the add-user.properties configuration file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1766) NAKACK2/UNICAST3: faster acceptance test

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1766?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1766: -------------------------------- I need to retract the previous comment: message batches received by NAKACK2 have the same dest: so either all messages in a batch have dest=null or all messages have dest!= null ! So the first comment is still valid and this optimization can be also be done for NAKACK2 ! > NAKACK2/UNICAST3: faster acceptance test > ---------------------------------------- > > Key: JGRP-1766 > URL: https://issues.jboss.org/browse/JGRP-1766 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > In NAKACK2/UNICAST3, when a message batch is received, we check every single message for presence of the corresponding header. If present we accept (and later process) the message. > A faster acceptance test would be to check if the destination of the message batch matches, e.g. > * UNICAST3: {{MessageBatch.getDest() != null}} > * NAKACK2: {{MessageBatch.getDest() == nul}} > If these conditions are false, we simply pass the batch up. This is faster than iterating through every message in the batch. > Same for single messages: this is already done in UNICAST3, but not in NAKACK2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2708) Solr fails to deploy on CR1

by Philipp Plogmann (JIRA)

[ https://issues.jboss.org/browse/WFLY-2708?page=com.atlassian.jira.plugin.... ] Philipp Plogmann commented on WFLY-2708: ---------------------------------------- Hi, I just encountered the same problem. This is caused by the implicit CDI scanning. See the Wildfly docs here: https://docs.jboss.org/author/display/WFLY8/CDI+Reference You can disable this for the whole application server by modifiying the subsystem entry in standalone.xml to <subsystem xmlns="urn:jboss:domain:weld:2.0" require-bean-descriptor="true"/> or you can modify the war and add the descriptor to it which avoids the implicit scanning. > Solr fails to deploy on CR1 > --------------------------- > > Key: WFLY-2708 > URL: https://issues.jboss.org/browse/WFLY-2708 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.CR1 > Reporter: Rich Midwinter > > Solr (4.6) fails to deploy on CR1. I've had it working previously on Alpha builds and I gather it worked previously on Beta builds for someone else experiencing this issue - https://issues.apache.org/jira/browse/SOLR-5578 > 2014-01-04 12:59:34,138 WARN [org.jboss.modules] (weld-worker-1) Failed to define class org.apache.hadoop.hdfs.web.resources.UserProvider in Module "deployment.solr.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link org/apache/hadoop/hdfs/web/re > sources/UserProvider (Module "deployment.solr.war:main" from Service Module Loader) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:428) [jboss-modules.jar:1.3.0.Final] > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261) [jboss-modules.jar:1.3.0.Final] > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76) [jboss-modules.jar:1.3.0.Final] > at org.jboss.modules.Module.loadModuleClass(Module.java:548) [jboss-modules.jar:1.3.0.Final] > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:189) [jboss-modules.jar:1.3.0.Final] > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final] > at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final] > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final] > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final] > at org.jboss.as.weld.WeldModuleResourceLoader.classForName(WeldModuleResourceLoader.java:68) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1] > at org.jboss.weld.bootstrap.BeanDeployer.loadClass(BeanDeployer.java:106) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59] > at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:94) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59] > at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:62) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59] > at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:60) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59] > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59] > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59] > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25] > at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > Caused by: java.lang.NoClassDefFoundError: com/sun/jersey/spi/inject/InjectableProvider > at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_25] > at java.lang.ClassLoader.defineClass(ClassLoader.java:792) [rt.jar:1.7.0_25] > at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:345) [jboss-modules.jar:1.3.0.Final] > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:423) [jboss-modules.jar:1.3.0.Final] > ... 20 more > Caused by: java.lang.ClassNotFoundException: com.sun.jersey.spi.inject.InjectableProvider from [Module "deployment.solr.war:main" from Service Module Loader] > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) [jboss-modules.jar:1.3.0.Final] > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final] > at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final] > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final] > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final] > ... 24 more > 2014-01-04 12:59:34,148 INFO [org.jboss.weld.Bootstrap] (weld-worker-1) WELD-000119: Not generating any bean definitions from org.apache.hadoop.hdfs.web.resources.UserProvider because of underlying class loading error: Type com.sun.jersey.spi.inject.InjectableProvider from [Module "deployment.solr.war:main" from Service Module Loader] not found. If this is unexpected, enable DEBUG logging to see the full error. > 2014-01-04 12:59:34,893 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."solr.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."solr.war".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Set<Service> with qualifiers @Default > at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject com.google.common.util.concurrent.ServiceManager(Set<Service>) > at com.google.common.util.concurrent.ServiceManager.<init>(ServiceManager.java:0) > at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:361) > at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:282) > at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:133) > at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:164) > at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:507) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25] > at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25] > ... 3 more > 2014-01-04 12:59:34,901 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "solr.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"solr.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"solr.war\".WeldStartService: Failed to start service -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2696) management audit settings: syslog protocol is lowercase while uppercase is expected

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2696?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2696: ----------------------------------------------- Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 1047536|https://bugzilla.redhat.com/show_bug.cgi?id=1047536] from MODIFIED to POST > management audit settings: syslog protocol is lowercase while uppercase is expected > ----------------------------------------------------------------------------------- > > Key: WFLY-2696 > URL: https://issues.jboss.org/browse/WFLY-2696 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.CR1 > Environment: - 8.0.0 CR1 + latest code in master > - domain mode > Reporter: Tom Fonteyne > Assignee: Tom Fonteyne > > Add a syslog handler to the audit settings of the management service of the domain controller, then start an instance. It fails to start with: > JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.IllegalArgumentException: No enum const class org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.udp > at java.lang.Enum.valueOf(Enum.java:214) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2618) Intermittent 'AssertionError: expected:<200> but was:<500>' in org.jboss.as.test.manualmode.ws.ReloadWSDLPublisherTestCase.testHelloStringAfterReload

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2618?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2618: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1034229, https://bugzilla.redhat.com/show_bug.cgi?id=1049796 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1034229) > Intermittent 'AssertionError: expected:<200> but was:<500>' in org.jboss.as.test.manualmode.ws.ReloadWSDLPublisherTestCase.testHelloStringAfterReload > ----------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-2618 > URL: https://issues.jboss.org/browse/WFLY-2618 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite > Affects Versions: 8.0.0.CR1 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Minor > > http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameI... > The issue is due to the fact that the jvm is reusing the same connection because it has a keep-alive set to true with a timeout of 5 s. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1766) NAKACK2/UNICAST3: faster acceptance test

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1766?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1766: -------------------------------- Same for message batches: we might receive a message batch whose dest is non-null in NAKACK2, but still have to process it by iterating over its messages, because some messages might be XMIT_RSP/XMIT_REQ messages ! However, we can *ignore message batches whose destination is null in UNICAST3*. This is actually the only thing that can be changed in this JIRA !! :-) > NAKACK2/UNICAST3: faster acceptance test > ---------------------------------------- > > Key: JGRP-1766 > URL: https://issues.jboss.org/browse/JGRP-1766 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > In NAKACK2/UNICAST3, when a message batch is received, we check every single message for presence of the corresponding header. If present we accept (and later process) the message. > A faster acceptance test would be to check if the destination of the message batch matches, e.g. > * UNICAST3: {{MessageBatch.getDest() != null}} > * NAKACK2: {{MessageBatch.getDest() == nul}} > If these conditions are false, we simply pass the batch up. This is faster than iterating through every message in the batch. > Same for single messages: this is already done in UNICAST3, but not in NAKACK2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1766) NAKACK2/UNICAST3: faster acceptance test

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1766?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1766: -------------------------------- CORRECTION: *we cannot do this for single messages in NAKACK2 !* The reason is that we might receive unicast messages, e.g. XMIT_REQ/XMIT_RSP messages, which need to get handled by NAKACK2... This does work in UNICAST3, because it's the opposite of NAKACK2: it will never handle multicast messages (dest == null). > NAKACK2/UNICAST3: faster acceptance test > ---------------------------------------- > > Key: JGRP-1766 > URL: https://issues.jboss.org/browse/JGRP-1766 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > In NAKACK2/UNICAST3, when a message batch is received, we check every single message for presence of the corresponding header. If present we accept (and later process) the message. > A faster acceptance test would be to check if the destination of the message batch matches, e.g. > * UNICAST3: {{MessageBatch.getDest() != null}} > * NAKACK2: {{MessageBatch.getDest() == nul}} > If these conditions are false, we simply pass the batch up. This is faster than iterating through every message in the batch. > Same for single messages: this is already done in UNICAST3, but not in NAKACK2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 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 January 2014