October 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1036) Upgrade to JBoss Remoting 4.0.15.Final

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1036?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1036: ------------------------------------- Fix Version/s: (was: 2.0.0.Final) > Upgrade to JBoss Remoting 4.0.15.Final > -------------------------------------- > > Key: WFCORE-1036 > URL: https://issues.jboss.org/browse/WFCORE-1036 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Remoting > Reporter: Darran Lofthouse > Assignee: David Lloyd > Fix For: 2.0.1.Final (EAP 7), 3.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-889) Kerberos authentication for Management CLI should fallback when server principal is set incorrectly

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-889?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-889: ------------------------------------ Fix Version/s: 2.0.1.Final (EAP 7) 3.0.0.Alpha1 (was: 2.0.0.Final) > Kerberos authentication for Management CLI should fallback when server principal is set incorrectly > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-889 > URL: https://issues.jboss.org/browse/WFCORE-889 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Fix For: 2.0.1.Final (EAP 7), 3.0.0.Alpha1 > > > In case when kerberos authentication is configured in security realm but principal attribute in keytab element is set incorrectly (e.g. remote/wrong_localhost(a)JBOSS.ORG, remote/localhost(a)WRONG_JBOSS.ORG or wrong_remote/localhost(a)JBOSS.ORG instead of remote/localhost(a)JBOSS.ORG) then authentication does not fallback into another authentication mechanism for user with valid kerberos ticket. In case when user does not have kerberos ticket then fallback is taken into account correctly. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1036) Upgrade to JBoss Remoting 4.0.15.Final

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1036?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1036: ------------------------------------- Fix Version/s: 2.0.1.Final (EAP 7) 3.0.0.Alpha1 > Upgrade to JBoss Remoting 4.0.15.Final > -------------------------------------- > > Key: WFCORE-1036 > URL: https://issues.jboss.org/browse/WFCORE-1036 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Remoting > Reporter: Darran Lofthouse > Assignee: David Lloyd > Fix For: 2.0.1.Final (EAP 7), 3.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1049) ConcreteResourceRegistration#registerSubModel is not thread safe

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1049?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1049: ------------------------------------- Fix Version/s: 3.0.0.Alpha1 (was: 2.0.0.Final) > ConcreteResourceRegistration#registerSubModel is not thread safe > ---------------------------------------------------------------- > > Key: WFCORE-1049 > URL: https://issues.jboss.org/browse/WFCORE-1049 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Stuart Douglas > Assignee: Brian Stansberry > Fix For: 3.0.0.Alpha1 > > > registerSubModel checks for existing, then registers, however it is invoked by two threads at the same time it is possible they will both see the resource as not existing and both register. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1083) Login Module is messed up when one of the module-option is empty

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1083?page=com.atlassian.jira.plugi... ] Alexey Loubyansky commented on WFCORE-1083: ------------------------------------------- It appears to be fixed in the current master which is WildFly 10.0.0.CR5 (wildfly-core 2.0.0.CR9). principalDNSPrefix will be stored as "undefined" in the XML. > Login Module is messed up when one of the module-option is empty > ---------------------------------------------------------------- > > Key: WFCORE-1083 > URL: https://issues.jboss.org/browse/WFCORE-1083 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Environment: CentOS Linux release 7.1.1503 (Core) > /usr/java/jdk1.8.0_45/ > WildFly 8.2.0 > Reporter: J Prasanna Venkatesan > Assignee: Alexey Loubyansky > Priority: Critical > > When one of the module-option is given as empty the whole login-module is messed up. But in real time there will be cases where the module-option can be empty. For Eg. while configuring org.jboss.security.auth.spi.LdapLoginModule, the principalDNPrefix can be empty > *+Command with principalDNPrefix empty+* > /subsystem=security/security-domain=SourceForge/authentication=classic/login-module=org.jboss.security.auth.spi.LdapLoginModule33:add(code=org.jboss.security.auth.spi.LdapLoginModule, flag=sufficient, module-options=[ "java.naming.provider.url" => "ldap://ldaphost.jboss.org:1", "java.naming.security.authentication" => "simple", *"principalDNPrefix" => ""*, "principalDNSuffix" => ",ou=People,o=jboss.org", "allowEmptyPasswords" => "false", "java.naming.factory.initial" => "com.sun.jndi.ldap.LdapCtxFactory", "throwValidateError" => "true" ]){allow-resource-service-restart=true} > +Output in standalone-full.xml+ > Wrong value is stored as principalDNPrefix > <login-module name="org.jboss.security.auth.spi.LdapLoginModule33" code="org.jboss.security.auth.spi.LdapLoginModule" flag="sufficient"> > <module-option name="java.naming.provider.url" value="ldap://ldaphost.jboss.org:1"/> > <module-option name="java.naming.security.authentication" value="simple"/> > *<module-option name="principalDNPrefix" value="principalDNSuffix"/>* > <module-option name="allowEmptyPasswords" value="false"/> > <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/> > <module-option name="throwValidateError" value="true"/> > </login-module> > *+Command with principalDNPrefix with some value+* > /subsystem=security/security-domain=SourceForge/authentication=classic/login-module=org.jboss.security.auth.spi.LdapLoginModule44:add(code=org.jboss.security.auth.spi.LdapLoginModule, flag=sufficient, module-options=[ "java.naming.provider.url" => "ldap://ldaphost.jboss.org:1", "java.naming.security.authentication" => "simple", *"principalDNPrefix" => "test"*, "principalDNSuffix" => ",ou=People,o=jboss.org", "allowEmptyPasswords" => "false", "java.naming.factory.initial" => "com.sun.jndi.ldap.LdapCtxFactory", "throwValidateError" => "true" ]){allow-resource-service-restart=true} > +Output in standalone-full.xml+ > Values are stored correctly. > <login-module name="org.jboss.security.auth.spi.LdapLoginModule44" code="org.jboss.security.auth.spi.LdapLoginModule" flag="sufficient"> > <module-option name="java.naming.provider.url" value="ldap://ldaphost.jboss.org:1"/> > <module-option name="java.naming.security.authentication" value="simple"/> > *<module-option name="principalDNPrefix" value="test"/>* > <module-option name="principalDNSuffix" value=",ou=People,o=jboss.org"/> > <module-option name="allowEmptyPasswords" value="false"/> > <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/> > <module-option name="throwValidateError" value="true"/> > </login-module> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-618) Thread deadlock on org.drools.util.CompositeClassLoader

by Satish Narayan (JIRA)

[ https://issues.jboss.org/browse/DROOLS-618?page=com.atlassian.jira.plugin... ] Satish Narayan commented on DROOLS-618: --------------------------------------- We ran into this as well. Is this truly a bug? Is there a safe work around? > Thread deadlock on org.drools.util.CompositeClassLoader > ------------------------------------------------------- > > Key: DROOLS-618 > URL: https://issues.jboss.org/browse/DROOLS-618 > Project: Drools > Issue Type: Bug > Affects Versions: 5.6.0.Final > Environment: drools expert > Reporter: Shashank Agarwal > Assignee: Mark Proctor > Attachments: http-54350-Processor15.txt, http-54350-Processor18.txt, http-54350-Processor20.txt > > > Sometimes we are facing issues of thread deadlock due to which our application goes unresponsive. Drools version 5.6.0 > Below is the deadlock statements detected by jconsole, also attached full tread dumps. There three threads are deadlocked triangularly. > Name: http-54350-Processor15 > State: BLOCKED on org.drools.rule.JavaDialectRuntimeData$PackageClassLoader@1d5787a owned by: http-54350-Processor18 > Name: http-54350-Processor18 > State: WAITING on java.util.concurrent.locks.ReentrantLock$NonfairSync@3cda324d owned by: http-54350-Processor15 > Name: http-54350-Processor20 > State: BLOCKED on org.drools.util.CompositeClassLoader@61269654 owned by: http-54350-Processor15 > We do not have definite threads to re-produce the issue. > But deadlocks are happening repeatedly on our production. > Regarding out environment details: > 1. We have windows box on which application runs. > 2. The rules used are kept in .drl and .xls formats > 3. Call StatefulKnowledgeSession session = base.newStatefulKnowledgeSession(); > 4. Setup a few session globals as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5614) org.hibernate:4.3 should not be alias for 5.0

by Scott Marlow (JIRA)

Scott Marlow created WFLY-5614: ---------------------------------- Summary: org.hibernate:4.3 should not be alias for 5.0 Key: WFLY-5614 URL: https://issues.jboss.org/browse/WFLY-5614 Project: WildFly Issue Type: Feature Request Components: JPA / Hibernate Affects Versions: 10.0.0.CR4 Reporter: Scott Marlow Assignee: Scott Marlow modules/system/layers/base/org/hibernate/4.3/module.xml contains: {quote} <module-alias xmlns="urn:jboss:module:1.3" name="org.hibernate" slot="4.3" target-name="org.hibernate"/> {quote} org.hibernate:4.3 should be a real module (not alias) like org.hibernate:4.1 is. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1090) Modules are missing jboss.api=private setting in module.xml

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1090: ---------------------------------------- Summary: Modules are missing jboss.api=private setting in module.xml Key: WFCORE-1090 URL: https://issues.jboss.org/browse/WFCORE-1090 Project: WildFly Core Issue Type: Bug Affects Versions: 2.0.0.CR9 Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 2.0.0.Final Following modules need to have the jboss.api=private property added to their module.xml: org.jboss.sasl org.jboss.as.self-contained sun.scripting org.wildfly.extension.io org.wildfly.extension.request-controller -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1089) IgnoredResourcesProfileCloneTestCase does not wait for domain stabilization following reload

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1089?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1089: ------------------------------------- Summary: IgnoredResourcesProfileCloneTestCase does not wait for domain stabilization following reload (was: IgnoredResourcesProfileCloneTestCase does not well for domain stabilization following reload) > IgnoredResourcesProfileCloneTestCase does not wait for domain stabilization following reload > -------------------------------------------------------------------------------------------- > > Key: WFCORE-1089 > URL: https://issues.jboss.org/browse/WFCORE-1089 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Test Suite > Affects Versions: 2.0.0.CR9 > Reporter: Brian Stansberry > > IgnoredResourcesProfileCloneTestCase several times reloads the slave HC without restarting its servers. But it then does not wait for those servers to reconnect before continuing on. This means the servers may not be reattached to the domain when further modifications are made. > I'm quite certain this is the cause of the failure at http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=76866&tab=buil... and the other time that test failed. > IgnoredResourcesProfileCloneTestCase reloads the slave and then exits. CompositeOperationTestCase follows and immediately adds system-property=composite-op in its @Before method. The other-two server doesn't get this op as it's not reconnected. The test then later fails because the other-two server's state is not as expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4866) messaging-activemq: NPE when http-acceptor and https-acceptor configured

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-4866?page=com.atlassian.jira.plugin.... ] Jeff Mesnil edited comment on WFLY-4866 at 10/30/15 10:24 AM: -------------------------------------------------------------- ARTEMIS-151 introduces a behaviour changes and no longer allows to have identical acceptor configurations (with different names). This means that in WildFly case, the https-acceptor is discarded because it defines the same configuration that the http-acceptor one. was (Author: jmesnil): ARTEMIS-151 introduce a behaviour changes and no longer allows to have identical acceptor configurations (with different names). This means that in WildFly case, the https-acceptor is discarded because it defines the same configuration that the http-acceptor one. > messaging-activemq: NPE when http-acceptor and https-acceptor configured > ------------------------------------------------------------------------ > > Key: WFLY-4866 > URL: https://issues.jboss.org/browse/WFLY-4866 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 8.1.0.Final, 10.0.0.CR2 > Environment: Windows 7 Pro, Java 7u55 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Labels: JMS, Messaging > Fix For: 10.0.0.CR3 > > Attachments: server-logs.zip > > > With both an http-acceptor and an https-acceptor configured in the message subsystem, when an external Java app attempts to connect, it times out and the exception below appears in the server log. > I tracked it down to the TransportConfigOperationHandlers.processAcceptors() method. At the end of the method, it creates a HashSet of the TransportConfiguration objects representing the acceptors. But, the TransportConfiguration equals() method reports that the https and http acceptors are equal, and as it is building a Set of unique values, the https-acceptor gets dropped. > Later, when the http-upgrade handshake runs, the code is unable to find the https-acceptor, resulting in the NullPointerException. > I think the fix might be to either not use a Set, or to look at the TransportConfiguration.equals() method. > The workaround in the ticket works because the redundant <param> causes the equals() method to see the two acceptors as unequal. > The exception was: > [exec] 10:07:57,502 ERROR [org.xnio.listener] (default I/O-10) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException > [exec] at org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:161) > [exec] at org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:153) > [exec] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final] > [exec] at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:149) > [exec] at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:271) > [exec] at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:221) > [exec] at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1131) > [exec] at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1351) > [exec] at io.undertow.server.Connectors.terminateResponse(Connectors.java:78) > [exec] at io.undertow.server.protocol.http.ServerFixedLengthStreamSinkConduit.channelFinished(ServerFixedLengthStreamSinkConduit.java:33) > [exec] at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.exitFlush(AbstractFixedLengthStreamSinkConduit.java:273) > [exec] at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:207) > [exec] at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) [xnio-api-3.2.2.Final.jar:3.2.2.Final] > [exec] at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100) > [exec] at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1489) > [exec] at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1470) > [exec] at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:152) > [exec] at io.undertow.server.handlers.ProxyPeerAddressHandler.handleRequest(ProxyPeerAddressHandler.java:45) > [exec] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) > [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:156) > [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:91) > [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:45) > [exec] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final] > [exec] at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.2.Final.jar:3.2.2.Final] > [exec] at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.2.Final.jar:3.2.2.Final] > [exec] at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

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 October 2015