October 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5452) Sometimes the calling javax.security.auth.login.Configuration.getConfiguration() fails with SecurityException in our tests

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-5452: ---------------------------------- Summary: Sometimes the calling javax.security.auth.login.Configuration.getConfiguration() fails with SecurityException in our tests Key: WFLY-5452 URL: https://issues.jboss.org/browse/WFLY-5452 Project: WildFly Issue Type: Bug Components: Test Suite Affects Versions: 10.0.0.CR2 Reporter: Ondrej Lukas Assignee: Ondrej Lukas Sometimes the calling javax.security.auth.login.Configuration.getConfiguration() fails with SecurityException in our tests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1030) PS1 scripts for standalone and domain do not survive :shutdown(restart=true)

by Rostislav Svoboda (JIRA)

Rostislav Svoboda created WFCORE-1030: ----------------------------------------- Summary: PS1 scripts for standalone and domain do not survive :shutdown(restart=true) Key: WFCORE-1030 URL: https://issues.jboss.org/browse/WFCORE-1030 Project: WildFly Core Issue Type: Bug Components: Scripts Reporter: Rostislav Svoboda Assignee: Tomaz Cerar PS1 scripts for standalone and domain do not survive :shutdown(restart=true) {code} [standalone@localhost:9990 /] :shutdown(restart=true) {"outcome" => "success"} [standalone@localhost:9990 /] ls Failed to perform operation: java.net.ConnectException: WFLYPRT0053: Could not connect to http-remoting://localhost:9990. The connection failed: WFLYPRT0053: Could not connect to http-remoting://localhost:9990. The connection failed: Connection refused: no further information {code} Domain the same {code} [domain@localhost:9990 /] /host=master:shutdown(restart=true) ... {code} FYI - scripts were taken from https://github.com/ctomc/wildfly-core/commits/powershell -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5451) LdapCacheInSecurityRealmsTestCase rarely fails with No additional LDAP search was expected

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-5451: ---------------------------------- Summary: LdapCacheInSecurityRealmsTestCase rarely fails with No additional LDAP search was expected Key: WFLY-5451 URL: https://issues.jboss.org/browse/WFLY-5451 Project: WildFly Issue Type: Bug Components: Test Suite Affects Versions: 10.0.0.CR2 Reporter: Ondrej Lukas Assignee: Ondrej Lukas LdapCacheInSecurityRealmsTestCase rarely fails with "No additional LDAP search was expected". Following tests are affected: testGroupToPrincipal testPrincipalToGroup testUsernameToDnFilter testUsernameToDnAdvanced -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-936) Add and enable enforcer rule which bans duplicated classes

by Petr Široký (JIRA)

Petr Široký created DROOLS-936: ---------------------------------- Summary: Add and enable enforcer rule which bans duplicated classes Key: DROOLS-936 URL: https://issues.jboss.org/browse/DROOLS-936 Project: Drools Issue Type: Enhancement Reporter: Petr Široký Assignee: Petr Široký Throughout the codebase there are modules which depend on artifacts which have duplicated classes (classes with same FQN). This is very much undesirable as at runtime one them just gets picked and there is no guarantee which one actually. There is an enforcer rule which checks all the dependencies and fails the build in case there are duplicated classes, http://www.mojohaus.org/extra-enforcer-rules/banDuplicateClasses.html. We should add this one to the build. Either to default one, or to "full" profile in case the build time would be considerable slower. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1962) Do not include the log4j2.xml resource in the released JGroups jar

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1962?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1962: -------------------------------- OK, I removed log4j2.xml and README from the JAR file. > Do not include the log4j2.xml resource in the released JGroups jar > ------------------------------------------------------------------ > > Key: JGRP-1962 > URL: https://issues.jboss.org/browse/JGRP-1962 > Project: JGroups > Issue Type: Task > Affects Versions: 3.6.4 > Reporter: Sanne Grinovero > Assignee: Bela Ban > Fix For: 3.6.6 > > > The {{log4j2.xml}} configuration file is included in JGroups, but this makes it hard to override the logging as this will likely conflict with other resources configured by end user applications. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1844) Remove shared transport

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1844?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1844: -------------------------------- I'll take a look at your explanation when I tackle this issue, but I can already tell you if this is an Infinispan issue, then it won't prevent me from removing the shared transport. In the worst casem you could always create full channels (with non-shared transports). No, FORK cannot be placed below GMS, or other protocols such as NAKACK2 or UNICAST3. It is really meant to be located towards the top of the stack. > Remove shared transport > ----------------------- > > Key: JGRP-1844 > URL: https://issues.jboss.org/browse/JGRP-1844 > Project: JGroups > Issue Type: Task > Affects Versions: 3.5 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > I'm thinking of deprecating the shared transport [1] and remove it in 4.0. The replacement would be fork channels [2]. > Here's my reasoning: > * Shared transports are quite a complex beast: initialization (ref counting), cluster-name and local-addr are not used in TP when shared, duplicate logic. Removing this will make the code base smaller > * All protocols *above* shared transports are not shared, e.g. FD_SOCK, NAKACK, UNICAST etc all maintain their own threads, retransmission tables, sockets etc. With fork channels, everything up to the FORK protocol *is* shared > * TUNNEL doesn't work with shared transports (throws an exception) > * Hidden insertion of TP$ProtocolAdapter into the stack when shared transports are used > * Unneeded cost of sending N-1 messages (e.g. with TCP). Currently we send a message with dest null and no IP multicast capable transport to all physical addresses in the transport, which is a waste > Thoughts ? My +100 for removing shared transports in 4.0... > [1] http://www.jgroups.org/manual/html/user-advanced.html#SharedTransport > [2] http://www.jgroups.org/manual/html/user-advanced.html#ForkChannel -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5450) Update to Hibernate Core 5.0.2.Final

by Martin Kamp Jensen (JIRA)

Martin Kamp Jensen created WFLY-5450: ---------------------------------------- Summary: Update to Hibernate Core 5.0.2.Final Key: WFLY-5450 URL: https://issues.jboss.org/browse/WFLY-5450 Project: WildFly Issue Type: Component Upgrade Reporter: Martin Kamp Jensen Assignee: Jason Greene Fix For: 10.0.0.Final Please, if possible, include the latest Hibernate Core bugfix release in the final version of WildFly 10. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-929) CLI is terminated unexpectedly after type "qui" on HPUX

by Dominik Pospisil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-929?page=com.atlassian.jira.plugin... ] Dominik Pospisil commented on WFCORE-929: ----------------------------------------- My findings so far: * Actually It's typing the 'u' character making the JVM to terminate * The "Aesh InputStream Reader" seems to be causing the termination * it happends somewhere on line AeshInputStream.readFromStream:126, it does not make it to line 127. Seems to be somewhere in JDK code. > CLI is terminated unexpectedly after type "qui" on HPUX > ------------------------------------------------------- > > Key: WFCORE-929 > URL: https://issues.jboss.org/browse/WFCORE-929 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 2.0.0.Beta4 > Reporter: Marek Kopecký > Assignee: Alexey Loubyansky > Priority: Minor > > *Description of problem:* > CLI is terminated unexpectedly after type "qui" on HPUX > *How reproducible:* > Always on HPUX > *Steps to Reproduce:* > # ./standalone.sh > # ./jboss-cli.sh -c > # qui > #* type "qui" in console to CLI, do not press "enter" > *Actual results:* > CLI is terminated > *Expected results:* > CLI is not terminated -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1029) ManagedSocketFactory doesn't work for client sockets

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1029?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration updated WFCORE-1029: -------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1268186 Bugzilla Update: Perform > ManagedSocketFactory doesn't work for client sockets > ---------------------------------------------------- > > Key: WFCORE-1029 > URL: https://issues.jboss.org/browse/WFCORE-1029 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 2.0.0.CR5 > Reporter: Dennis Reed > > SocketBindingManagerImpl does not work with client sockets. > It adds sockets to a map based on local address. Client sockets that have not been bound yet do not have a local address. > This breaks the JGroups subsystem's ManagedSocketFactory, which uses SocketBindingManagerImpl for both server and client sockets. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5449) Custom socket factory for JGroups subsystem not set correctly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5449?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-5449: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1268185 Bugzilla Update: Perform > Custom socket factory for JGroups subsystem not set correctly > ------------------------------------------------------------- > > Key: WFLY-5449 > URL: https://issues.jboss.org/browse/WFLY-5449 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR2 > Reporter: Dennis Reed > Assignee: Paul Ferraro > > Wildfly's JChannelFactory tries to set a custom socket factory on the JGroups transport. > This is not the correct API to use, and it gets overwritten when the JGroups channel starts. > A custom socket factory should be set on the JChannel. > The only time the custom socket factory is currently used is if there's a race condition where two channels are started at the same time, and the custom factory is set just before the other channel uses it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 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 October 2015