November 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SECURITY-770) Support external password for keystore of PicketBoxVault implementation

by Ivo Studensky (JIRA)

Ivo Studensky created SECURITY-770: -------------------------------------- Summary: Support external password for keystore of PicketBoxVault implementation Key: SECURITY-770 URL: https://issues.jboss.org/browse/SECURITY-770 Project: PicketBox Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JBossSX Affects Versions: PicketBox_4_0_19.Final Reporter: Ivo Studensky Assignee: Ivo Studensky At the moment, the default implementation of Vault supports masked keystore password only. It would be nice to add a facility for external keystore password too so that customers can either define an external command to get the password or define their own class which provides a password for the keystore. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2574) CliArgumentsTestCase should not rely on java beeing on path

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFLY-2574?page=com.atlassian.jira.plugin.... ] Alexey Loubyansky resolved WFLY-2574. ------------------------------------- Fix Version/s: 8.0.0.CR1 Resolution: Done Fixed in the master. > CliArgumentsTestCase should not rely on java beeing on path > ------------------------------------------------------------ > > Key: WFLY-2574 > URL: https://issues.jboss.org/browse/WFLY-2574 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CLI, Test Suite > Affects Versions: 8.0.0.Beta1 > Reporter: Tomaz Cerar > Assignee: Alexey Loubyansky > Priority: Critical > Fix For: 8.0.0.CR1 > > > If there is no java on path tests fail with > {noformat} > java.lang.AssertionError: Failed to start CLI process: Cannot run program "java": error=2, No such file or directory > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.test.integration.management.cli.CliScriptTestBase.execute(CliScriptTestBase.java:108) > at org.jboss.as.test.integration.management.cli.CliScriptTestBase.execute(CliScriptTestBase.java:73) > at org.jboss.as.test.integration.management.cli.CliScriptTestBase.execute(CliScriptTestBase.java:69) > at org.jboss.as.test.integration.management.cli.CliArgumentsTestCase.testConnectArgument(CliArgumentsTestCase.java:103) > {noformat} > Test should use JAVA_HOME env variable or java that ran "current" process > without this fix it is really hard to properly test build with different JDKs as test will always use default java for executing commands instead of build provided/configured one -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1750) RELAY2 : Address formats are not relayed.

by Karim AMMOUS (JIRA)

Karim AMMOUS created JGRP-1750: ---------------------------------- Summary: RELAY2 : Address formats are not relayed. Key: JGRP-1750 URL: https://issues.jboss.org/browse/JGRP-1750 Project: JGroups Issue Type: Feature Request Affects Versions: 3.4.1 Reporter: Karim AMMOUS Assignee: Bela Ban When defining a relay channel, we haven't the ability to set an AddressGenrator. Indeed, the Relayer uses its own AddressGenerator providing addresses of type SiteUUID. This is particularly embarrassing in the following case: when we define a customized address format (like CanBeSiteMasterTopology or TopologyUUID) for members of two Sites A and B, address format is lost by crossing relay. Address type of messages sent by A to B are seen as SiteUUID at B side. Suggestions: - Making address format "relayable" ? - Using the same (or an extended format) AddressGenerator of site Channel -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-356) KieScanner doesn't work on a KieContainer using a maven version range

by Mark Proctor (JIRA)

[ https://issues.jboss.org/browse/DROOLS-356?page=com.atlassian.jira.plugin... ] Mark Proctor commented on DROOLS-356: ------------------------------------- Some background for this. When a KieModule is looked up, it allows a version String. The KieModule resolves a jar using Maven. As such engineers expect it to support any standard Maven convention for Strings. But it did not support versions. Further it would lose the original version request; such as -SNAPSHOT. So scanNow would not pick up the latest. The change allows any Maven version string to be passed, as any engineer would expect, and to ensure that original string is used each time scanNow is called. The current work around is to create an empty wrapper project, to control deployment updates. This project's pom would be resolved by maven, and thus all version syntax is supported and corrected resolved. > KieScanner doesn't work on a KieContainer using a maven version range > --------------------------------------------------------------------- > > Key: DROOLS-356 > URL: https://issues.jboss.org/browse/DROOLS-356 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.0.1.Final > > > It is currently possible to create a KieContainer with a ranged version instead of a fixed one, but this range is not used by the KieScanner that instead consider only the fixed version of the first fetched 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1120) Allow disabling of core and jdbc statistics via configuration

by John O'Hara (JIRA)

John O'Hara created JBJCA-1120: ---------------------------------- Summary: Allow disabling of core and jdbc statistics via configuration Key: JBJCA-1120 URL: https://issues.jboss.org/browse/JBJCA-1120 Project: IronJacamar Issue Type: Feature Request Components: Core, JDBC Affects Versions: 1.0.24.Final Reporter: John O'Hara Assignee: Jesper Pedersen Priority: Minor >From our performance testing, we are able to improve system response time by crudely eliminating runtime statistics. Av. system response time(s) from our performance testing, each metric represents a different operation within the performance test; With statistics enabled; 0.035s/0.245s/1.515s/0.685s/1.975s With statistics disabled; 0.035s/0.059s/0.578s/0.278s/0.756s We need to be able to disable statistics in JdbcStatisticsPlugin and ManagedConnectionPoolStatisticsImpl (plus anywhere else runtime statistics are generated) via a configuration option. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2588) HC Main.getHostSystemProperties() does not handle additional equals in system properties properly

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-2588?page=com.atlassian.jira.plugin.... ] Kabir Khan reassigned WFLY-2588: -------------------------------- Assignee: Kabir Khan (was: Brian Stansberry) > HC Main.getHostSystemProperties() does not handle additional equals in system properties properly > ------------------------------------------------------------------------------------------------- > > Key: WFLY-2588 > URL: https://issues.jboss.org/browse/WFLY-2588 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Beta1 > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 8.0.0.CR1 > > > -Djava.security.policy==/Users/kabir/tmp/permit.policy (note the extra '=') is a valid setting to just use that policy file (unlike -Djava.security.policy=/Users/kabir/tmp/permit.policy which adds it to the system wide and user policies) > Main.getHostSystemProperties() currently handles this in a way that the value becomes null, while it should be '=/Users/kabir/tmp/permit.policy' which causes this problem when starting up the servers > {code} > [Server:server-one] Exception in thread "main" java.security.AccessControlException: access denied (java.util.PropertyPermission module.path write) > [Server:server-one] at java.security.AccessControlContext.checkPermission(AccessControlContext.java:376) > [Server:server-one] at java.security.AccessController.checkPermission(AccessController.java:549) > [Server:server-one] at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) > [Server:server-one] at java.lang.System.setProperty(System.java:741) > [Server:server-one] at org.jboss.modules.Main.main(Main.java:148) > {code} -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1748) Diagnostics: change size of printed views dynamically

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1748?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1748. ---------------------------- Resolution: Done Examples: probe.sh max-list-print-size=30 probe.sh max-list-print-size > Diagnostics: change size of printed views dynamically > ----------------------------------------------------- > > Key: JGRP-1748 > URL: https://issues.jboss.org/browse/JGRP-1748 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.5 > > > Currently, when a view or digest is longer than Util.MAX_LIST_PRINT_SIZE (20 by default) elements, we don't print the entire list, but only the first 20 elements, followed by an ellipsis. Util.MAX_LIST_PRINT_SIZE is defined via system prop "max.list.print_size". > Use probe / JMX to dynamically change the value of Util.MAX_LIST_PRINT_SIZE. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1748) Diagnostics: change size of printed views dynamically

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1748?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1748: --------------------------- Summary: Diagnostics: change size of printed views dynamically (was: Change size of printed views dynamically) > Diagnostics: change size of printed views dynamically > ----------------------------------------------------- > > Key: JGRP-1748 > URL: https://issues.jboss.org/browse/JGRP-1748 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.5 > > > Currently, when a view or digest is longer than Util.MAX_LIST_PRINT_SIZE (20 by default) elements, we don't print the entire list, but only the first 20 elements, followed by an ellipsis. Util.MAX_LIST_PRINT_SIZE is defined via system prop "max.list.print_size". > Use probe / JMX to dynamically change the value of Util.MAX_LIST_PRINT_SIZE. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2588) HC Main.getHostSystemProperties() does not handle additional equals in system properties properly

by Kabir Khan (JIRA)

Kabir Khan created WFLY-2588: -------------------------------- Summary: HC Main.getHostSystemProperties() does not handle additional equals in system properties properly Key: WFLY-2588 URL: https://issues.jboss.org/browse/WFLY-2588 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Domain Management Affects Versions: 8.0.0.Beta1 Reporter: Kabir Khan Assignee: Brian Stansberry Fix For: 8.0.0.CR1 -Djava.security.policy==/Users/kabir/tmp/permit.policy (note the extra '=') is a valid setting to just use that policy file (unlike -Djava.security.policy=/Users/kabir/tmp/permit.policy which adds it to the system wide and user policies) Main.getHostSystemProperties() currently handles this in a way that the value becomes null, while it should be '=/Users/kabir/tmp/permit.policy' which causes this problem when starting up the servers {code} [Server:server-one] Exception in thread "main" java.security.AccessControlException: access denied (java.util.PropertyPermission module.path write) [Server:server-one] at java.security.AccessControlContext.checkPermission(AccessControlContext.java:376) [Server:server-one] at java.security.AccessController.checkPermission(AccessController.java:549) [Server:server-one] at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) [Server:server-one] at java.lang.System.setProperty(System.java:741) [Server:server-one] at org.jboss.modules.Main.main(Main.java:148) {code} -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-356) KieScanner doesn't work on a KieContainer using a maven version range

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-356?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-356: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1035685|https://bugzilla.redhat.com/show_bug.cgi?id=1035685] from NEW to ASSIGNED > KieScanner doesn't work on a KieContainer using a maven version range > --------------------------------------------------------------------- > > Key: DROOLS-356 > URL: https://issues.jboss.org/browse/DROOLS-356 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > > It is currently possible to create a KieContainer with a ranged version instead of a fixed one, but this range is not used by the KieScanner that instead consider only the fixed version of the first fetched 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

12 years, 7 months

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 November 2013