March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3162) audit syslog handler should be able to automatically reconnect

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3162?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-3162: ----------------------------------- Assignee: (was: John Doyle) > audit syslog handler should be able to automatically reconnect > -------------------------------------------------------------- > > Key: WFLY-3162 > URL: https://issues.jboss.org/browse/WFLY-3162 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final > Reporter: Tom Fonteyne > > When the syslog server goes down, WF will retry (up to 10 times we believe) to reconnect but will then give up. You can manually force a reconnect by issuing: > /host=master/core-service=management/access=audit/syslog-handler=mysyslog:recycle > This request is to make it possible to automate this and make it configurable at which interval it should try and reconnect -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3162) audit syslog handler should be able to automatically reconnect

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3162?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-3162: ----------------------------------- Labels: EAP (was: ) > audit syslog handler should be able to automatically reconnect > -------------------------------------------------------------- > > Key: WFLY-3162 > URL: https://issues.jboss.org/browse/WFLY-3162 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final > Reporter: Tom Fonteyne > Labels: EAP > > When the syslog server goes down, WF will retry (up to 10 times we believe) to reconnect but will then give up. You can manually force a reconnect by issuing: > /host=master/core-service=management/access=audit/syslog-handler=mysyslog:recycle > This request is to make it possible to automate this and make it configurable at which interval it should try and reconnect -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3162) audit syslog handler should be able to automatically reconnect

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3162?page=com.atlassian.jira.plugin.... ] Brian Stansberry moved PRODMGT-773 to WFLY-3162: ------------------------------------------------ Project: WildFly (was: Product Management) Key: WFLY-3162 (was: PRODMGT-773) Workflow: GIT Pull Request workflow (was: JBoss Platforms RFE Workflow v2) Affects Version/s: 8.0.0.Final (was: 6) Component/s: Domain Management (was: Enterprise Application Platform (EAP)) Security: Public > audit syslog handler should be able to automatically reconnect > -------------------------------------------------------------- > > Key: WFLY-3162 > URL: https://issues.jboss.org/browse/WFLY-3162 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final > Reporter: Tom Fonteyne > Assignee: John Doyle > > When the syslog server goes down, WF will retry (up to 10 times we believe) to reconnect but will then give up. You can manually force a reconnect by issuing: > /host=master/core-service=management/access=audit/syslog-handler=mysyslog:recycle > This request is to make it possible to automate this and make it configurable at which interval it should try and reconnect -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1801) DuplicateTest fails when testing OOB multicast to all three senders

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/JGRP-1801?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on JGRP-1801: ------------------------------------------- I managed to reproduce this issue locally on my Windows 7 partition, which, thankfully, is also slow as the machines in the QA lab. To recap, the failures occur for both TCP and UDP, and involve OOB multicast messages. Messages from one of the senders do not get through. Here are some new debugging results: - disable the OOB thread pool, the tests always pass on both UDP and TCP - enable the OOB thread pool, I always seem to get at least one failure on both TCP and UDP So, it appears this issue has something to do with use of the OOB thread pool. I also noticed that the assertion which is failing (the assertion which checks that at least some messages from all three senders has arrived) is checked after 10 seconds. Because this is not a performance test, there is no harm in extending this timeout to, say, 60 seconds. > DuplicateTest fails when testing OOB multicast to all three senders > ------------------------------------------------------------------- > > Key: JGRP-1801 > URL: https://issues.jboss.org/browse/JGRP-1801 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: Windows (18), Solaris (2), RHEL(1) where (x) is the number of failures seen > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.2.14 > > > DuplicateTest does the following: > - creates three channels containing the DUPL layer called c1, c2, c3 > - DUPL is used to duplicate messages sent > - channel receiver for channel each keeps a map of messages received from each sender > - channels send messages: regular, OOB, or mixed > - the test checks that the messages received by each channel are correct in number and in order > The test testOOBMuloticastToAll3Senders is failing regularly on multple platforms. The test makes each of the channels send OOB multicast messages to the group, but only two of three members ever end up receiving the multicast messages. Al example of the failure: > {noformat} > Error Message > expected size=3, msgs: [C2, C1] > Stacktrace > java.lang.AssertionError > at org.jgroups.tests.DuplicateTest.check(DuplicateTest.java:217) > at org.jgroups.tests.DuplicateTest.testOOBMulticastToAll3Senders(DuplicateTest.java:123) > {noformat} -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3144) Session replication doesn't work as expected

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3144?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-3144: ------------------------------------ Assignee: Paul Ferraro (was: Stuart Douglas) > Session replication doesn't work as expected > -------------------------------------------- > > Key: WFLY-3144 > URL: https://issues.jboss.org/browse/WFLY-3144 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld, Clustering, EJB > Affects Versions: 8.0.0.Final > Reporter: Tomas Remes > Assignee: Paul Ferraro > Attachments: translator.zip > > > I am experimenting with quite simple Stateful SessionScoped bean ( see org.jboss.weld.tests.clustering.translator.TranslatorControllerBean from attached reproducer) and actually there's not any specific exception, but the behavior is at least weird. I haven't tried with plain EJB so far. Reproducible by following steps: > 1. Run first node with "/bin/standalone.sh -c standalone-ha.xml" > 2. Run second node with "./bin/standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=second" > 3. Build and deploy attached reproducer > 4. Open 127.0.0.1:8080/translator in your browser and translate something. > 5. Open 127.0.0.1:8180/translator and note that number of translated sentences is not replicated correctly. > This works correctly in EAP. I am running with default standalone-ha configuration on oracle's 1.7.0_45 jdk. -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-101) Each custom log handler defined in standalone adds a root log4j console appender

by John L (JIRA)

John L created JBLOGGING-101: -------------------------------- Summary: Each custom log handler defined in standalone adds a root log4j console appender Key: JBLOGGING-101 URL: https://issues.jboss.org/browse/JBLOGGING-101 Project: JBoss Logging Issue Type: Bug Security Level: Public (Everyone can see) Components: jboss-logging-log4j Reporter: John L Assignee: James Perkins JBoss 7.1.3 Logging custom handlers which are used to wrap existing log4j handlers into jboss logging handlers calls org.jboss.as.logging.handlers.custom.PropertiesConfigurator which calls org.apache.log4j.BasicConfigurator.configure() which by default adds a ConsoleAppender. Maybe should be calling org.apache.log4j.BasicConfigurator.configure(new NullAppender()); to initialize log4j. Net result is all log4j messages get forwarded to jboss logging add also get sent to the default ConsoleAppender which then writes it out stdout which then jboss catches as stdout. So we have 3 custom handlers in our jboss configuration so we get 4 messages to the screen. (1 for real category and 3 for each console appender added). Not sure if this is reported in correct project. -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2950) jboss-cli using https-remoting: command not executed if certificate is unrecognised

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2950?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2950: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1026418|https://bugzilla.redhat.com/show_bug.cgi?id=1026418] from MODIFIED to ON_QA > jboss-cli using https-remoting: command not executed if certificate is unrecognised > ----------------------------------------------------------------------------------- > > Key: WFLY-2950 > URL: https://issues.jboss.org/browse/WFLY-2950 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CLI, Domain Management > Affects Versions: 8.0.0.Final > Environment: Windows 7 Pro > Reporter: Darren Jones > Assignee: Darran Lofthouse > Labels: cli, shutdown > Fix For: 8.0.1.Final > > > When using the https management interface from jboss-cli, commands passed with a command line option (such as --command=:shutdown) are not executed if the server certificate is unrecognised - even if accepting the certificate [T]emporarily or [P]ermenantly. > It appears to be due to the CommandContextImpl.handleSSLFailure() method, which calls error("Unable to connect..."). The error() method sets the exitCode to 1. So, when CliLauncher.processCommands() subsequently runs, it sees that the cmdCtx.exitCode is 1 and ignores any commands. > I guess the handleSSLFailure needs to reset the exitCode to 0 if the user chooses [T] or [P]. -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-805) Overload SecurityVaultFactory.get() to be able to specify the classloader

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-805?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-805: -------------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1079930|https://bugzilla.redhat.com/show_bug.cgi?id=1079930] from MODIFIED to ON_QA > Overload SecurityVaultFactory.get() to be able to specify the classloader > ------------------------------------------------------------------------- > > Key: SECURITY-805 > URL: https://issues.jboss.org/browse/SECURITY-805 > Project: PicketBox > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: PicketBox_4_0_21.Beta2, PicketBox_4_0_19.SP5 > > Attachments: SECURITY-805-2.diff, SECURITY-805.diff > > > To work better with modular class loading in WF -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2214) Allow additional environment properties to be set for outbound LDAP connections used by security realms.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2214: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1015303|https://bugzilla.redhat.com/show_bug.cgi?id=1015303] from MODIFIED to ON_QA > Allow additional environment properties to be set for outbound LDAP connections used by security realms. > -------------------------------------------------------------------------------------------------------- > > Key: WFLY-2214 > URL: https://issues.jboss.org/browse/WFLY-2214 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Alpha4 > Reporter: Derek Horton > Assignee: Darran Lofthouse > Fix For: 8.0.0.CR1 > > > LDAP security realm needs to have configurable timeouts. > The default LDAP connection timeout appears to be 2 minutes. If the ldap server is down, it could take 2 minutes for the connection to timeout. This can cause unneeded delay if you have configured multiple ldap servers for failover / redundancy. > The following hack appears to work: > +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java > @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag > result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory); > String url = config.require(URL).asString(); > result.put(Context.PROVIDER_URL,url); > + result.put("com.sun.jndi.ldap.connect.timeout", "500"); > return result; > } -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2538) Certificate acceptance causing command entered on starting the CLI to be skipped.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2538?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2538: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1026418|https://bugzilla.redhat.com/show_bug.cgi?id=1026418] from MODIFIED to ON_QA > Certificate acceptance causing command entered on starting the CLI to be skipped. > --------------------------------------------------------------------------------- > > Key: WFLY-2538 > URL: https://issues.jboss.org/browse/WFLY-2538 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CLI > Affects Versions: 8.0.0.Beta1 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.0.0.CR1 > > > e.g. > {noformat} > ./jboss-cli.sh -c shutdown > Accept certificate? [N]o, [T]emporarily, [P]ermenantly : T > {noformat} > The shutdown command is not executed. -- 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

10 years, 9 months

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 March 2014