June 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6736) Removing children of security-realm always finishes with {"outcome" => "success"}

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-6736?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-6736: ---------------------------------------- Management security realms are all a part of WildFly Core - please move these issues to the WFCORE project. > Removing children of security-realm always finishes with {"outcome" => "success"} > --------------------------------------------------------------------------------- > > Key: WFLY-6736 > URL: https://issues.jboss.org/browse/WFLY-6736 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 10.0.0.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > > Removing children of security-realm (e.g. authentication) always finishes with {"outcome" => "success"}. This happens even if type of children of security-realm does not exist in server configuration. It should rather finish with failure to indicate that nothing was removed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6738) Load tld files from <ear>/lib/*.jar archives

by Tomas Repel (JIRA)

Tomas Repel created WFLY-6738: --------------------------------- Summary: Load tld files from <ear>/lib/*.jar archives Key: WFLY-6738 URL: https://issues.jboss.org/browse/WFLY-6738 Project: WildFly Issue Type: Enhancement Components: Web (Undertow) Affects Versions: 10.0.0.Final Reporter: Tomas Repel Assignee: Stuart Douglas Let's assume there is EAR archive that contains WAR archive that contains WEB-INF/lib/some.jar file that contains /META-INF/some-tag-library.tld. Such deployment works. However, instead, if having EAR archive that contains lib/some.jar file that contains /META-INF/some-tag-library.tld (and of course the EAR archive contains the WAR archive as in the previous case), the tag library is not loaded. Simple reproducer: https://github.com/trepel/primrose-hibernate-simple/tree/tlddiscovery -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6737) Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6737?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-6737: ------------------------------- Affects Version/s: 10.0.0.Final > Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used > --------------------------------------------------------------------------------------------------------- > > Key: WFLY-6737 > URL: https://issues.jboss.org/browse/WFLY-6737 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 10.0.0.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > > When security-realm, which is set as http-interface security-realm in management-interfaces, is modified and operation used {allow-resource-service-restart=true} header then server is NOT in reload-required state but modified security realm does not work correctly until server is manually reloaded. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6737) Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-6737: ---------------------------------- Summary: Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used Key: WFLY-6737 URL: https://issues.jboss.org/browse/WFLY-6737 Project: WildFly Issue Type: Bug Components: Domain Management Reporter: Ondrej Lukas Assignee: Brian Stansberry When security-realm, which is set as http-interface security-realm in management-interfaces, is modified and operation used {allow-resource-service-restart=true} header then server is NOT in reload-required state but modified security realm does not work correctly until server is manually reloaded. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6736) Removing children of security-realm always finishes with {"outcome" => "success"}

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-6736: ---------------------------------- Summary: Removing children of security-realm always finishes with {"outcome" => "success"} Key: WFLY-6736 URL: https://issues.jboss.org/browse/WFLY-6736 Project: WildFly Issue Type: Bug Components: Domain Management Reporter: Ondrej Lukas Assignee: Brian Stansberry Removing children of security-realm (e.g. authentication) always finishes with {"outcome" => "success"}. This happens even if type of children of security-realm does not exist in server configuration. It should rather finish with failure to indicate that nothing was removed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6736) Removing children of security-realm always finishes with {"outcome" => "success"}

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6736?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-6736: ------------------------------- Affects Version/s: 10.0.0.Final > Removing children of security-realm always finishes with {"outcome" => "success"} > --------------------------------------------------------------------------------- > > Key: WFLY-6736 > URL: https://issues.jboss.org/browse/WFLY-6736 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 10.0.0.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > > Removing children of security-realm (e.g. authentication) always finishes with {"outcome" => "success"}. This happens even if type of children of security-realm does not exist in server configuration. It should rather finish with failure to indicate that nothing was removed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6735) Processing stucks for ~12 seconds when ManagementRealm is changed with {allow-resource-service-restart=true}

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-6735: ---------------------------------- Summary: Processing stucks for ~12 seconds when ManagementRealm is changed with {allow-resource-service-restart=true} Key: WFLY-6735 URL: https://issues.jboss.org/browse/WFLY-6735 Project: WildFly Issue Type: Bug Components: Domain Management Reporter: Ondrej Lukas Assignee: Brian Stansberry When any operation which changes configuration (add, remove, write-attribute...) is executed on any children of security-realm (e.g. authentication) with {allow-resource-service-restart=true} operation header, then processing stucks for ~12 seconds. This happens only in case when changed security-realm is set as http-interface security-realm in management-interfaces. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6735) Processing stucks for ~12 seconds when ManagementRealm is changed with {allow-resource-service-restart=true}

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6735?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-6735: ------------------------------- Affects Version/s: 10.0.0.Final > Processing stucks for ~12 seconds when ManagementRealm is changed with {allow-resource-service-restart=true} > ------------------------------------------------------------------------------------------------------------ > > Key: WFLY-6735 > URL: https://issues.jboss.org/browse/WFLY-6735 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 10.0.0.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > > When any operation which changes configuration (add, remove, write-attribute...) is executed on any children of security-realm (e.g. authentication) with {allow-resource-service-restart=true} operation header, then processing stucks for ~12 seconds. > This happens only in case when changed security-realm is set as http-interface security-realm in management-interfaces. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6734) Server should expose information about available modules

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6734?page=com.atlassian.jira.plugin.... ] Tomaz Cerar closed WFLY-6734. ----------------------------- Fix Version/s: 10.0.0.Final Assignee: Tomaz Cerar (was: Jason Greene) Resolution: Out of Date This information is avalbile in jmx and also via mgmt api since WFCORE-570 was implemented in 10.0 > Server should expose information about available modules > -------------------------------------------------------- > > Key: WFLY-6734 > URL: https://issues.jboss.org/browse/WFLY-6734 > Project: WildFly > Issue Type: Feature Request > Components: Server > Reporter: Ivan Straka > Assignee: Tomaz Cerar > Priority: Minor > Fix For: 10.0.0.Final > > > It would be great if server exposed information about available modules. > *Example of usage:* > * Run WildFly > * go to Configuration -> Subsystems -> Infinispan > * pick any cache container > * click on Add > Set module can not be verified right now, therefore user may set wrong module without noticing. Moreover there could be some helper for available modules. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (REMJMX-107) Operation failed with status WAITING

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-107?page=com.atlassian.jira.plugin... ] Darran Lofthouse resolved REMJMX-107. ------------------------------------- Fix Version/s: (was: 2.0.1.Final) Resolution: Rejected Please take questions like this to the forums, Jira is used for tracking bugs and features being worked on not general help discussions. http://wildfly.org/gethelp/ > Operation failed with status WAITING > ------------------------------------ > > Key: REMJMX-107 > URL: https://issues.jboss.org/browse/REMJMX-107 > Project: Remoting JMX > Issue Type: Feature Request > Components: Connection > Affects Versions: 2.0.1.Final > Reporter: Olga Pavluchenko > Assignee: Darran Lofthouse > Attachments: standalone.xml > > > Hay, guys! > I have a constant problem with connect to JBoss JMX, and I didn.t search any result for this issue. > Maybe is problem in standalone.xml? I attach it. > In my IDE I see this log file: > {code:java} > Cannot resolve reference to bean 'configManager' while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'configManager': Invocation of init method failed; nested exception is javax.naming.NamingException: Failed to create remoting connection [Root exception is java.lang.RuntimeException: Operation failed with status WAITING] > at org.springframework.context.annotation.CommonAnnotationBeanPostProcessor.postProcessPropertyValues(CommonAnnotationBeanPostProcessor.java:308) > at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1186) > at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:537) > at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:475) > at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:302) > at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:229) > at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:298) > {code} > {code:java} > Caused by: javax.naming.NamingException: Failed to create remoting connection [Root exception is java.lang.RuntimeException: Operation failed with status WAITING] > at org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:36) > at org.jboss.naming.remote.client.InitialContextFactory.getInitialContext(InitialContextFactory.java:121) > at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) > at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) > at javax.naming.InitialContext.init(InitialContext.java:244) > at javax.naming.InitialContext.<init>(InitialContext.java:216) > at org.springframework.jndi.JndiTemplate.createInitialContext(JndiTemplate.java:136) > at org.springframework.jndi.JndiTemplate.getContext(JndiTemplate.java:103) > {code} > But in serve log file I don't have useful info, only something like this: > {code:java} > 16:09:46,330 INFO [org.jboss.as.naming] (Remoting "prod-jboss-ws-1" task-4) JBAS011806: Channel end notification received, closing channel Channel ID 353b2878 (inbound) of Remoting connection 7f445270 to null > 16:12:16,861 INFO [org.jboss.as.naming] (Remoting "prod-jboss-ws-1" task-1) JBAS011806: Channel end notification received, closing channel Channel ID 01d0e554 (inbound) of Remoting connection 548b1385 to null > 16:12:18,553 INFO [org.jboss.as.naming] (Remoting "prod-jboss-ws-1" task-1) JBAS011806: Channel end notification received, closing channel Channel ID 11534d5a (inbound) of Remoting connection 557970fd to null > 16:12:18,959 INFO [org.jboss.as.naming] (Remoting "prod-jboss-ws-1" task-1) JBAS011806: Channel end notification received, closing channel Channel ID 5eda2124 (inbound) of Remoting connection 654fb197 to null > 16:12:19,295 INFO [org.jboss.as.naming] (Remoting "prod-jboss-ws-1" task-4) JBAS011806: Channel end notification received, closing channel Channel ID 6daae8f2 (inbound) of Remoting connection 3b6776c8 to null > 16:13:45,748 INFO [org.jboss.as.naming] (Remoting "prod-jboss-ws-1" task-1) JBAS011806: Channel end notification received, closing channel Channel ID 3b562d89 (inbound) of Remoting connection 4ec5353c to null > {code} > {code:java} > "Remoting "prod-jboss-ws-1" task-4" prio=10 tid=0x00007f8740100000 nid=0x65d0 waiting on condition [0x00007f87c9c96000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x000000068a7ca258> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) > at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043) > at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) > at org.xnio.LimitedBlockingQueue.take(LimitedBlockingQueue.java:95) > at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:724) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

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 2016