November 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-283) SASL_SERVER and SASL_PROTOCOL options not being passed all the way to Remoting

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-283?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-283: ------------------------------------------------ Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1168313|https://bugzilla.redhat.com/show_bug.cgi?id=1168313] from POST to MODIFIED > SASL_SERVER and SASL_PROTOCOL options not being passed all the way to Remoting > ------------------------------------------------------------------------------ > > Key: WFCORE-283 > URL: https://issues.jboss.org/browse/WFCORE-283 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Remoting, Security > Affects Versions: 1.0.0.Alpha13 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4132) Transaction subsystem does not initialise the recovery store correctly

by Michael Musgrove (JIRA)

Michael Musgrove created WFLY-4132: -------------------------------------- Summary: Transaction subsystem does not initialise the recovery store correctly Key: WFLY-4132 URL: https://issues.jboss.org/browse/WFLY-4132 Project: WildFly Issue Type: Bug Components: Transactions Affects Versions: 9.0.0.Alpha1 Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 9.0.0.Beta1 The initialisation code in the transaction subsystem sets the transaction log directory on the wrong instance (https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java...). The code should pass in the null string for the instance name to get the default instance. The bug arises because we recently fixed JBTM-2207 in order to avoid string comparison with the default name and the reason this is not a backwards compatibility issue is that com.arjuna.common.internal.util.propertyservice.BeanPopulator is internal code that the app server is using. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-286) The SecurityRealmService should only perform a generic mapping to RealmUser if really required.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-286?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-286: ------------------------------------------------ Darran Lofthouse <darran.lofthouse(a)redhat.com> changed the Status of [bug 1168595|https://bugzilla.redhat.com/show_bug.cgi?id=1168595] from ASSIGNED to POST > The SecurityRealmService should only perform a generic mapping to RealmUser if really required. > ----------------------------------------------------------------------------------------------- > > Key: WFCORE-286 > URL: https://issues.jboss.org/browse/WFCORE-286 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha13 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > > If there is a more accurate way to calculate the RealmUser then use it. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-195) Outbound LDAP connection in domain mode test case

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-195?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-195: ------------------------------------------------ Hynek Mlnarik <hmlnarik(a)redhat.com> changed the Status of [bug 1148400|https://bugzilla.redhat.com/show_bug.cgi?id=1148400] from ON_QA to VERIFIED > Outbound LDAP connection in domain mode test case > ------------------------------------------------- > > Key: WFCORE-195 > URL: https://issues.jboss.org/browse/WFCORE-195 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security, Test Suite > Affects Versions: 1.0.0.Alpha11 > Reporter: Ondrej Kotek > Assignee: Ondrej Kotek > Fix For: 1.0.0.Alpha11 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-286) The SecurityRealmService should only perform a generic mapping to RealmUser if really required.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-286?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-286: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1168595 > The SecurityRealmService should only perform a generic mapping to RealmUser if really required. > ----------------------------------------------------------------------------------------------- > > Key: WFCORE-286 > URL: https://issues.jboss.org/browse/WFCORE-286 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha13 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > > If there is a more accurate way to calculate the RealmUser then use it. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4131) TransportConfiguration does not check the name in equals

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-4131: --------------------------------- Summary: TransportConfiguration does not check the name in equals Key: WFLY-4131 URL: https://issues.jboss.org/browse/WFLY-4131 Project: WildFly Issue Type: Bug Components: JMS Affects Versions: 8.1.0.Final Environment: Windows 7 Pro, Java 7u55 Reporter: Jeff Mesnil Assignee: Jeff Mesnil 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.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4129) The RemotingLoginModule should first check if there is already a RealmUser

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4129?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4129: ----------------------------------------------- Darran Lofthouse <darran.lofthouse(a)redhat.com> changed the Status of [bug 1168585|https://bugzilla.redhat.com/show_bug.cgi?id=1168585] from ASSIGNED to POST > The RemotingLoginModule should first check if there is already a RealmUser > -------------------------------------------------------------------------- > > Key: WFLY-4129 > URL: https://issues.jboss.org/browse/WFLY-4129 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 9.0.0.Alpha1 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > > The reason is because the realm may have actually already substituted in a different name for the user. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-160) Bash scripts should not attempt to expand argument properties

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-160?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-160: ------------------------------------------------ Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1145960|https://bugzilla.redhat.com/show_bug.cgi?id=1145960] from ON_QA to VERIFIED > Bash scripts should not attempt to expand argument properties > ------------------------------------------------------------- > > Key: WFCORE-160 > URL: https://issues.jboss.org/browse/WFCORE-160 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.0.0.Alpha10 > > > Scripts that parse the command line arguments use a pattern like > {code} > while [ "$#" -gt 0 ] > do > case "$1" in > *) > CLI_OPTS="$CLI_OPTS \"$1\"" > ;; > esac > shift > done > {code} > The {{CLI_OPTS="$CLI_OPTS \"$1\""}} should be {{CLI_OPTS="$CLI_OPTS '$1'"}} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4129) The RemotingLoginModule should first check if there is already a RealmUser

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4129?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-4129: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1168585 > The RemotingLoginModule should first check if there is already a RealmUser > -------------------------------------------------------------------------- > > Key: WFLY-4129 > URL: https://issues.jboss.org/browse/WFLY-4129 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 9.0.0.Alpha1 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > > The reason is because the realm may have actually already substituted in a different name for the user. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-199) The entire kie 6.3 build should move maven from 3.0.5 to 3.2.x

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-199?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer commented on DROOLS-199: ----------------------------------------------- did a mvn clean install -Dfull -DskipTests with apache_maven_3.2.3 and droolsjbpm-tools did not build: https://gist.github.com/mbiarnes/32f48e28aed298a35dcf repeated a mvn clean install -Dfull -DskipTests with apache_maven_3.0.5 and it worked. there is something with the tycho plugin. > The entire kie 6.3 build should move maven from 3.0.5 to 3.2.x > -------------------------------------------------------------- > > Key: DROOLS-199 > URL: https://issues.jboss.org/browse/DROOLS-199 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > Old description: > To reproduce: > - Install maven 3.1.0 > - Run mvn-all.sh clean install -Dfull > Note: Any changes to the pom must still allow them to run with 3.0.5 too. > 1) At least droolsjbpm-tools (drools-eclipse) is guaranteed to fail because it uses an older tycho version and only tycho 0.18.1 is compatible with maven 3.1.0 according to the tycho mailing list. > So the maven tycho plugin will need to be upgraded to 0.18.1 (which works with maven 3.0.5 too - so they say). > 2) There might be other surprises... -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2014